All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfsprogs: fix geometry calls on older kernels for 5.2.1
Date: Tue, 20 Aug 2019 14:18:28 -0700	[thread overview]
Message-ID: <20190820211828.GC1037350@magnolia> (raw)
In-Reply-To: <7d83cd0d-8a15-201e-9ebf-e1f859270b92@sandeen.net>

On Tue, Aug 20, 2019 at 03:47:29PM -0500, Eric Sandeen wrote:
> I didn't think 5.2.0 through; the udpate of the geometry ioctl means
> that the tools won't work on older kernels that don't support the
> v5 ioctls, since I failed to merge Darrick's wrappers.
> 
> As a very quick one-off I'd like to merge this to just revert every
> geometry call back to the original ioctl, so it keeps working on
> older kernels and I'll release 5.2.1.  This hack can go away when
> Darrick's wrappers get merged.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>

For the four line code fix,
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>

> ---
> 
> I'm a little concerned that 3rd party existing code which worked fine
> before will now get the new XFS_IOC_FSGEOMETRY definition if they get
> rebuilt, and suddenly stop working on older kernels. Am I overreacting
> or misunderstanding our compatibility goals?

As for this question ^^^ ... <URRRK>.

I thought the overall strategy was to get everything in xfsprogs using
libfrog wrappers that would degrade gracefully on old kernels.

For xfsdump/restore, I think we should just merge it into xfsprogs and
then it can use our wrappers.

For everything else... I thought the story was that you shouldn't really
be using xfs ioctls unless you're keeping up with upstream.

<shrug> Feel free to differ, that's just a braindump of my shattered
mind. :P

--D

> diff --git a/libxfs/xfs_fs.h b/libxfs/xfs_fs.h
> index f1158a79..253b706c 100644
> --- a/libxfs/xfs_fs.h
> +++ b/libxfs/xfs_fs.h
> @@ -720,7 +720,10 @@ struct xfs_scrub_metadata {
>  #define XFS_IOC_ATTRMULTI_BY_HANDLE  _IOW ('X', 123, struct xfs_fsop_attrmulti_handlereq)
>  #define XFS_IOC_FSGEOMETRY_V4	     _IOR ('X', 124, struct xfs_fsop_geom_v4)
>  #define XFS_IOC_GOINGDOWN	     _IOR ('X', 125, uint32_t)
> -#define XFS_IOC_FSGEOMETRY	     _IOR ('X', 126, struct xfs_fsop_geom)
> +/* For backwards compatibility in 5.2.1, just for now */
> +/* #define XFS_IOC_FSGEOMETRY	     _IOR ('X', 126, struct xfs_fsop_geom_v5) */
> +#define XFS_IOC_FSGEOMETRY XFS_IOC_FSGEOMETRY_V4
> +
>  /*	XFS_IOC_GETFSUUID ---------- deprecated 140	 */
>  
>  /* reflink ioctls; these MUST match the btrfs ioctl definitions */
> 

  reply	other threads:[~2019-08-20 21:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 20:47 [PATCH] xfsprogs: fix geometry calls on older kernels for 5.2.1 Eric Sandeen
2019-08-20 21:18 ` Darrick J. Wong [this message]
2019-08-20 22:46   ` Dave Chinner
2019-08-21 15:39     ` 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=20190820211828.GC1037350@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --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.