From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Date: Mon, 18 Mar 2019 23:01:12 +0000 Subject: [Cluster-devel] [PATCH 1/2] gfs2: Convert gfs2 to fs_context In-Reply-To: <8b0534dc-0ee0-ba7f-8709-30433c04c5a7@redhat.com> References: <8b0534dc-0ee0-ba7f-8709-30433c04c5a7@redhat.com> <20190317174027.15291-2-anprice@redhat.com> <20190317174027.15291-1-anprice@redhat.com> <28293.1552915099@warthog.procyon.org.uk> Message-ID: <27152.1552950072@warthog.procyon.org.uk> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andrew Price wrote: > > Umm... What about the fs_context struct? Why can't that be used to > > propagate the bdev pointer? That's kind of what it's for... > > It would be useful to have the block device pointer in the fs_context since so > many of the filesystems use them and it makes for an obvious API migration. That may be so. I've argued also that we should put a net-namespace pointer in there, but Al disagreed. However, I think most bdev-based filesystems use mount_bdev() which gfs2 does not. > > It looks like you should be able to stash the bdev pointer in the gfs2_args > > struct. > > Sure, but since the new API is young I figured I'd hold off until we had this > conversation because adding it to the fs_context might be agreeable :) Note that I have patches to kill of sget_userns() and sget() will hopefully soon follow. Have a look at: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=mount-api-viro David