Re: [PATCH 2/3] Btrfs: update subvol_getflags/setflags to know new args from user

On 07/03/2012 07:27 PM, Alexander Block wrote:

On Fri, Jun 29, 2012 at 11:59 AM, Liu Bo [off-list ref] wrote:

quoted

I've modified 'btrfs subvolume list' to show a subvolume's attributes,
such as readonly and default, and adopted a new structure for args for
subvol_getflags/setflags.

So here is the kernel side update.

Signed-off-by: Liu Bo <redacted>
---
 fs/btrfs/ioctl.c |  100 ++++++++++++++++++++++++++++++++++++++++-------------
 fs/btrfs/ioctl.h |    5 +++
 2 files changed, 80 insertions(+), 25 deletions(-)

[...]

quoted

diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index 3186d2d..1fa0ce2 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h

@@ -45,6 +45,11 @@ struct btrfs_ioctl_vol_args_v2 {
        char name[BTRFS_SUBVOL_NAME_MAX + 1];
 };

+struct btrfs_ioctl_get_set_flags_args {
+       __u64 objectid;
+       __u64 flags;
+};
+

Shouldn't BTRFS_IOC_SUBVOL_GETFLAGS/BTRFS_IOC_SUBVOL_SETFLAGS also be
updated? Both still have __u64 as arguments. Also, my patches for the
new btrfs prop command group won't work anymore due to the change in
the ioctl. I'm in the middle of preparing btrfs send/receive to be
sent to the list...I also use the ioctls there and we should agree on
what to do with the ioctls before I send the patches out.

Just drop this patch, I've discussed with Ilya about it (and also CCed you).

If we've more properties pending to set/get, 'btrfs property' will be better.

So please go on your work, I'll try to rebase my patch on yours.

thanks,
liubo

quoted

 /*
  * structure to report errors and progress to userspace, either as a
  * result of a finished scrub, a canceled scrub or a progress inquiry
--
1.6.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html