All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Dave Chinner <david@fromorbit.com>,
	Eric Sandeen <sandeen@redhat.com>,
	xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: remove unused xfs_ioctl32.h declarations
Date: Tue, 18 Jan 2022 11:06:38 -0800	[thread overview]
Message-ID: <20220118190638.GE13540@magnolia> (raw)
In-Reply-To: <230711ee-631f-0c3a-b07f-268d5504a197@sandeen.net>

On Tue, Jan 18, 2022 at 12:50:12PM -0600, Eric Sandeen wrote:
> On 1/18/22 12:30 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Remove these unused ia32 compat declarations; all the bits involved have
> > either been withdrawn or hoisted to the VFS.
> 
> Hm, don't we still have all the non-compat counterparts still live in
> fs/xfs/libxfs/xfs_fs.h, or am I not keeping up?
> 
> #define XFS_IOC_RESVSP		_IOW ('X', 40, struct xfs_flock64)
> #define XFS_IOC_UNRESVSP	_IOW ('X', 41, struct xfs_flock64)
> #define XFS_IOC_RESVSP64	_IOW ('X', 42, struct xfs_flock64)
> #define XFS_IOC_UNRESVSP64	_IOW ('X', 43, struct xfs_flock64)
> #define XFS_IOC_ZERO_RANGE	_IOW ('X', 57, struct xfs_flock64)
> 
> Why remove the compat ones but leave the abo ve? Aren't these all valid and
> tested ioctls, just under a different #define, and therefore harmless and
> also useful for backwards compatibility?
> 
> I feel like I'm missing something. :)

The implementation of those five ioctls (including all the ioctl32
compat noise) were hoisted to the VFS by Al and Christoph back in 2019.
Hence the #defines in xfs_ioctl32.h are no longer referenced by any
kernel code.  However, they missed the opportunity to remove these
definitions.

The struct compat_xfs_flock64 was still in use by the allocsp/freesp
xfs_ioctl32 code, but now that we're erasing it from history, it can go.

The definitions in xfs_fs.h have to be kept around because we export
them to userspace via /usr/include/xfs/xfs_fs.h.

--D

> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >   fs/xfs/xfs_ioctl32.h |   18 ------------------
> >   1 file changed, 18 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_ioctl32.h b/fs/xfs/xfs_ioctl32.h
> > index fc5a91f3a5e0..c14852362fce 100644
> > --- a/fs/xfs/xfs_ioctl32.h
> > +++ b/fs/xfs/xfs_ioctl32.h
> > @@ -142,24 +142,6 @@ typedef struct compat_xfs_fsop_attrmulti_handlereq {
> >   	_IOW('X', 123, struct compat_xfs_fsop_attrmulti_handlereq)
> >   #ifdef BROKEN_X86_ALIGNMENT
> > -/* on ia32 l_start is on a 32-bit boundary */
> > -typedef struct compat_xfs_flock64 {
> > -	__s16		l_type;
> > -	__s16		l_whence;
> > -	__s64		l_start	__attribute__((packed));
> > -			/* len == 0 means until end of file */
> > -	__s64		l_len __attribute__((packed));
> > -	__s32		l_sysid;
> > -	__u32		l_pid;
> > -	__s32		l_pad[4];	/* reserve area */
> > -} compat_xfs_flock64_t;
> > -
> > -#define XFS_IOC_RESVSP_32	_IOW('X', 40, struct compat_xfs_flock64)
> > -#define XFS_IOC_UNRESVSP_32	_IOW('X', 41, struct compat_xfs_flock64)
> > -#define XFS_IOC_RESVSP64_32	_IOW('X', 42, struct compat_xfs_flock64)
> > -#define XFS_IOC_UNRESVSP64_32	_IOW('X', 43, struct compat_xfs_flock64)
> > -#define XFS_IOC_ZERO_RANGE_32	_IOW('X', 57, struct compat_xfs_flock64)
> > -
> >   typedef struct compat_xfs_fsop_geom_v1 {
> >   	__u32		blocksize;	/* filesystem (data) block size */
> >   	__u32		rtextsize;	/* realtime extent size		*/
> > 

  reply	other threads:[~2022-01-18 19:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-18 18:30 [PATCH] xfs: remove unused xfs_ioctl32.h declarations Darrick J. Wong
2022-01-18 18:50 ` Eric Sandeen
2022-01-18 19:06   ` Darrick J. Wong [this message]
2022-01-18 23:41 ` 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=20220118190638.GE13540@magnolia \
    --to=djwong@kernel.org \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.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.