[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z1x+7gtJkfl8Q+pT@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Date: Sat, 14 Dec 2024 00:07:34 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: "Darrick J. Wong" <djwong@...nel.org>, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org, Ritesh Harjani <ritesh.list@...il.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Andrey Albershteyn <aalbersh@...nel.org>,
John Garry <john.g.garry@...cle.com>
Subject: Re: [RFC 1/3] include/linux.h: Factor out generic
platform_test_fs_fd() helper
On Thu, Dec 12, 2024 at 09:57:01PM -0800, Christoph Hellwig wrote:
> On Wed, Dec 11, 2024 at 10:09:02AM -0800, Darrick J. Wong wrote:
> > > +
> > > +static __inline__ int platform_test_ext4_fd(int fd)
> > > +{
> > > + return platform_test_fs_fd(fd, 0xef53); /* EXT4 magic number */
> >
> > Should this be pulling EXT4_SUPER_MAGIC from linux/magic.h?
>
> I think we can just drop adding platform_test_ext4_fd with the
> suggested patches later in the series? Having ext4-specific code
> in xfsprogs would seem pretty odd in xfsprogs anyway over our previous
> categories of xfs only or generic.
>
Oh right, xfs_io is so widely used across FSes that I missed to consider it
might not be okay to add special code specific to ext4 :)
Anyways, I agree we don't need to separately handle ext4 anymore. I'll
drop this patch. (Maybe still get XFS_SUPER_MAGIC from linux/magic.h as
that seems like the right thing to do)
Regards,
ojaswin
Powered by blists - more mailing lists