On Fri, May 11, 2018 at 09:36:09AM -0500, Eric Sandeen wrote: > On 5/11/18 9:32 AM, Chris Mason wrote: > > On 11 May 2018, at 10:10, David Sterba wrote: > > > >> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote: > >>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote: > >>>> Move the btrfs label ioctls up to the vfs for general use. > >>>> > >>>> This retains 256 chars as the maximum size through the interface, which > >>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum > >>>> label size. > >>>> > >>>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > >>>> Reviewed-by: Andreas Dilger <adilger@xxxxxxxxx> > >>>> Reviewed-by: David Sterba <dsterba@xxxxxxxx> > >>> > >>> No objections (and it obviously ought to go through btrfs tree). > >> > >> I can take it through my tree, but Eric mentioned that there's a patch > >> for xfs that depends on it. In this case it would make sense to take > >> both patches at once via the xfs tree. There are no pending conflicting > >> changes in btrfs. > > > > Probably easiest to just have a separate pull dedicated just for this series. That way it doesn't really matter which tree it goes through. > > Actually, I just realized that the changes to include/uapi/linux/fs.h are completely > independent of any btrfs changes, right - there's nothing wrong w/ redefining > the common ioctl under a different name in btrfs. So the fs.h patch could go first, > through the xfs tree since it'll be using it. > > Once the common ioctl definition goes in, then btrfs can change to define its ioctls to > the common ioctls, or act on them directly as my patch did, etc. Would that be > a better plan? IOWs there's no urgent need to coordinate a btrfs change. Agreed, I like that plan.
