From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sandeen.net ([63.231.237.45]:55696 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752873AbeEKOgL (ORCPT ); Fri, 11 May 2018 10:36:11 -0400 Subject: Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs To: Chris Mason , David Sterba Cc: Al Viro , Eric Sandeen , fsdevel , linux-btrfs@vger.kernel.org, Linux API References: <4a4f33c3-2173-9795-f4e4-1e9d338fd9a7@sandeen.net> <20180510191608.GR30522@ZenIV.linux.org.uk> <20180511141017.GZ6649@twin.jikos.cz> <9F0DCA90-AD82-4179-B50A-F112CF966CCB@fb.com> From: Eric Sandeen Message-ID: <94b5a947-d7f5-19e7-fb2b-161a5c20e85e@sandeen.net> Date: Fri, 11 May 2018 09:36:09 -0500 MIME-Version: 1.0 In-Reply-To: <9F0DCA90-AD82-4179-B50A-F112CF966CCB@fb.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 >>>> Reviewed-by: Andreas Dilger >>>> Reviewed-by: David Sterba >>> >>> 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. -Eric