All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: linux-cachefs@redhat.com,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Steve French <sfrench@samba.org>,
	Dominique Martinet <asmadeus@codewreck.org>,
	David Wysochanski <dwysocha@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	Jeffle Xu <jefflexu@linux.alibaba.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org,
	linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 12/19] netfs: Add a netfs inode context
Date: Wed, 09 Mar 2022 14:46:52 -0500	[thread overview]
Message-ID: <beaf4f6a6c2575ed489adb14b257253c868f9a5c.camel@kernel.org> (raw)
In-Reply-To: <1790300.1646853782@warthog.procyon.org.uk>

On Wed, 2022-03-09 at 19:23 +0000, David Howells wrote:
> Jeff Layton <jlayton@kernel.org> wrote:
> 
> > > Add a netfs_i_context struct that should be included in the network
> > > filesystem's own inode struct wrapper, directly after the VFS's inode
> > > struct, e.g.:
> > > 
> > > 	struct my_inode {
> > > 		struct {
> > > 			struct inode		vfs_inode;
> > > 			struct netfs_i_context	netfs_ctx;
> > > 		};
> > 
> > This seems a bit klunky.
> > 
> > I think it'd be better encapsulation to give this struct a name (e.g.
> > netfs_inode) and then have the filesystems replace the embedded
> > vfs_inode with a netfs_inode.
> 
> I think what you really want is:
> 
> 	struct my_inode : netfs_inode {
> 	};
> 
> right? ;-)
> 

Sort of, I guess.  The natural way to enforce the requirement that the
inode and context be ordered and adjacent like that is to make a struct
that embeds them both.

My thinking was that someone at some point will try to move things
around if they're just adjacent like this rather than an encapsulated
"object".

If we go this route, then please leave some comments in each filesystem
warning people off from breaking them up.

> > That way it's still just pointer math to get to the context from the
> > inode and vice versa, but the replacement seems a bit cleaner.
> > 
> > It might mean a bit more churn in the filesystems themselves as you
> > convert them, but most of them use macros or inline functions as
> > accessors so it shouldn't be _too_ bad.
> 
> That's a lot of churn - and will definitely cause conflicts with other
> patches aimed at those filesystems.  I'd prefer to avoid that if I can.
> 

Good point. Looks like around 200 or so places that would need to change
in the affected filesystems.

> > > +static int ceph_init_request(struct netfs_io_request *rreq, struct file *file)
> > > +{
> > > ...
> > > +}
> > > +
> > 
> > ^^^
> > The above change seems like it should be in its own patch. Wasn't it at
> > one point? Converting this to use init_request doesn't seem to rely on
> > the new embedded context.
> 
> Well, I wrote it as a separate patch on the end for convenience, but I
> intended to merge it here otherwise ceph wouldn't be able to do readahead for
> a few patches.
> 
> I was thinking that it would require the context change to work and certainly
> it requires the error-return-from-init_request patch to work, but actually it
> probably doesn't require the former so I could probably separate that bit out
> and put it between 11 and 12.
> 

Ok.

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2022-03-09 20:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 23:24 [PATCH v2 00/19] netfs: Prep for write helpers David Howells
2022-03-08 23:25 ` [PATCH v2 01/19] fscache: export fscache_end_operation() David Howells
2022-03-09 15:26   ` Jeff Layton
2022-03-10  1:40     ` JeffleXu
2022-03-08 23:25 ` [PATCH v2 02/19] netfs: Generate enums from trace symbol mapping lists David Howells
2022-03-09 15:30   ` Jeff Layton
2022-03-09 15:49   ` David Howells
2022-03-09 18:39     ` Jeff Layton
2022-03-08 23:25 ` [PATCH v2 03/19] netfs: Rename netfs_read_*request to netfs_io_*request David Howells
2022-03-09 15:31   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 04/19] netfs: Finish off rename of netfs_read_request to netfs_io_request David Howells
2022-03-09 15:34   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 05/19] netfs: Split netfs_io_* object handling out David Howells
2022-03-09 15:44   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 06/19] netfs: Adjust the netfs_rreq tracepoint slightly David Howells
2022-03-09 15:45   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 07/19] netfs: Trace refcounting on the netfs_io_request struct David Howells
2022-03-08 23:27 ` [PATCH v2 08/19] netfs: Trace refcounting on the netfs_io_subrequest struct David Howells
2022-03-08 23:27 ` [PATCH v2 09/19] netfs: Adjust the netfs_failure tracepoint to indicate non-subreq lines David Howells
2022-03-08 23:28 ` [PATCH v2 10/19] netfs: Refactor arguments for netfs_alloc_read_request David Howells
2022-03-08 23:28 ` [PATCH v2 11/19] netfs: Change ->init_request() to return an error code David Howells
2022-03-09 16:52   ` Jeff Layton
2022-03-08 23:28 ` [PATCH v2 12/19] netfs: Add a netfs inode context David Howells
2022-03-09 18:22   ` Jeff Layton
2022-03-09 19:23   ` David Howells
2022-03-09 19:46     ` Jeff Layton [this message]
2022-03-08 23:29 ` [PATCH v2 13/19] netfs: Add a function to consolidate beginning a read David Howells
2022-03-09 19:26   ` Jeff Layton
2022-03-09 22:08   ` David Howells
2022-03-08 23:29 ` [PATCH v2 14/19] netfs: Prepare to split read_helper.c David Howells
2022-03-08 23:29 ` [PATCH v2 15/19] netfs: Rename read_helper.c to io.c David Howells
2022-03-08 23:29 ` [PATCH v2 16/19] netfs: Split fs/netfs/read_helper.c David Howells
2022-03-09 20:27   ` Jeff Layton
2022-03-08 23:29 ` [PATCH v2 17/19] netfs: Split some core bits out into their own file David Howells
2022-03-08 23:29 ` [PATCH v2 18/19] netfs: Keep track of the actual remote file size David Howells
2022-03-09 20:45   ` Jeff Layton
2022-03-09 22:27   ` David Howells
2022-03-08 23:30 ` [PATCH v2 19/19] afs: Maintain netfs_i_context::remote_i_size David Howells
2022-03-09 21:12   ` Jeff Layton
2022-03-09 22:35   ` David Howells

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=beaf4f6a6c2575ed489adb14b257253c868f9a5c.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=anna.schumaker@netapp.com \
    --cc=asmadeus@codewreck.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=dwysocha@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=sfrench@samba.org \
    --cc=torvalds@linux-foundation.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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.