All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Eric Sandeen <sandeen@redhat.com>,
	linux-fsdevel@vger.kernel.org, david@fromorbit.com
Subject: Re: [PATCH 1/2] fs: Replace direct ->bmap calls by bmap()
Date: Thu, 6 Sep 2018 10:04:37 +0200	[thread overview]
Message-ID: <20180906080437.jwz6qtoo36uuw7ce@odin.usersys.redhat.com> (raw)
In-Reply-To: <20180905185539.GA423@lst.de>

On Wed, Sep 05, 2018 at 08:55:39PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 05, 2018 at 09:23:26AM -0500, Eric Sandeen wrote:
> > >  	block0 = page->index;
> > >  	block0 <<= shift;
> > >  
> > > -	block = inode->i_mapping->a_ops->bmap(inode->i_mapping, block0);
> > > +	block = bmap(inode, block0);
> > 
> > Prior to this there's an ASSERT that inode->i_mapping->a_ops->bmap
> > exists.  Should that stay, if the goal is to move all ->bmap use out
> > of calling code?
> 
> I think it needs to go away.

/me will keep it in mind
> 
> > OTOH, what will this code do if bmap() finds that there
> > is no ->bmap present and returns 0?
> 
> I think we just need to fix the bmap() prototype so that it can return
> error, which would be very useful for various reasons.  Something like
> this:
> 
> int bmap(struct address_space *mapping, sector_t *block)
> {
> 	if (!mapping->a_ops->bmap)
> 		return -EINVAL;
> 	*block = mapping->a_ops->bmap(mapping, *block);
> 	return 0;
> }
> 
> then add fiemap support with real error handling later.

Will do, thanks for the suggestion.


-- 
Carlos

  reply	other threads:[~2018-09-06 12:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 13:57 [PATCH RFC 0/2] ->bmap interface retirement Carlos Maiolino
2018-09-05 13:57 ` [PATCH 1/2] fs: Replace direct ->bmap calls by bmap() Carlos Maiolino
2018-09-05 14:23   ` Eric Sandeen
2018-09-05 18:55     ` Christoph Hellwig
2018-09-06  8:04       ` Carlos Maiolino [this message]
2018-09-06  8:03     ` Carlos Maiolino
2018-09-05 13:57 ` [PATCH 2/2] Use fiemap internal infra-structure to handle FIBMAP Carlos Maiolino
2018-09-05 14:31   ` Matthew Wilcox
2018-09-05 18:56     ` Christoph Hellwig
2018-09-06  8:31       ` Carlos Maiolino
2018-09-10  7:50         ` Christoph Hellwig
2018-09-10 10:31           ` Carlos Maiolino
2018-09-26 13:34           ` Carlos Maiolino
2018-09-06  8:18     ` Carlos Maiolino
2018-09-05 14:40   ` Eric Sandeen
2018-09-06  8:12     ` Carlos Maiolino
2018-09-06 15:53       ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180906080437.jwz6qtoo36uuw7ce@odin.usersys.redhat.com \
    --to=cmaiolino@redhat.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.