[RFC PATCHv2 0/3] Btrfs-progs: introduce btrfs property subgroup
This patchset introduces the btrfs property subgroup. It is the result of a discussion we had on IRC. I tried to make the properties interface as generic and extensible as possible. Comments are welcome. Currently the command group looks like this: btrfs prop set [-t type] /path/to/object name value btrfs prop get [-t type] /path/to/object [name] (omitting name dumps all) btrfs prop list [-t type] /path/to/object (lists properties with description) The type is used to explicitly specify what type of object you mean. This is necessary in case the object+property combination is ambiguous. For example '/path/to/fs/root' could mean the root subvolume, the directory inode or the filesystem itself. Normally, btrfs-progs will try to detect the type automatically. David suggested that it should also be possible to specify objects by their id/uuid/fsid. I like that idea, but would be happy if someone else could take over that part :) For now, I've implemented two properties: 1. read-only. Usable on subvolumes to toggle the read-only flags. 2. label. I looked through btrfs to find good examples of things that could be moved to the new properties interface and the filesystem label looked like a good one. There are for sure more, but that is something for later (and maybe for someone else). I would suggest to move everthing that makes sense over to the props interface and mark the old interfaces as deprecated. Comments on this are welcome. Patch version history: v1 Initial version. v2 - Removed the filesystem prefix and implemented it as new command group - Switched from the name[=value] form to the set/get name [value] form. - Removed patches Btrfs-progs: make filesystem_cmd_group non const and Btrfs-progs: move skip_prefix and prefixcmp to utils.c. They are not needed anymore due to the 'btrfs prop list' command. - Udjusted the subvol flags patch to be compatible to the Btrfs: use _IOR for BTRFS_IOC_SUBVOL_GETFLAGS patch. - Using -t type instead of type: prefix now. - Changes are based on feedback from Ilya and David. Alex. Alexander Block (3): Btrfs-progs: add BTRFS_IOC_SUBVOL_GET/SETFLAGS to ioctl.h Btrfs-progs: let get_label return the label instead of of printing it Btrfs-progs: introduce btrfs property subgroup Makefile |5 +- btrfs.c |1 + btrfslabel.c | 13 +- btrfslabel.h |4 +- cmds-filesystem.c | 14 +- cmds-property.c | 459 + commands.h|2 + ioctl.h |2 + props.c | 114 + props.h | 43 + 10 files changed, 645 insertions(+), 12 deletions(-) create mode 100644 cmds-property.c create mode 100644 props.c create mode 100644 props.h -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 0/3] Btrfs-progs: introduce btrfs property subgroup
Hi Alexander, On 06/27/2012 03:16 PM, Alexander Block wrote: This patchset introduces the btrfs property subgroup. It is the result of a discussion we had on IRC. I tried to make the properties interface as generic and extensible as possible. Comments are welcome. Currently the command group looks like this: btrfs prop set [-t type] /path/to/object name value btrfs prop get [-t type] /path/to/object [name] (omitting name dumps all) btrfs prop list [-t type] /path/to/object (lists properties with description) The type is used to explicitly specify what type of object you mean. This is necessary in case the object+property combination is ambiguous. For example '/path/to/fs/root' could mean the root subvolume, the directory inode or the filesystem itself. Normally, btrfs-progs will try to detect the type automatically. Instead of using btrfs prop set -t filesystem btrfs prop set -t subvolume btrfs prop set -t inode what about btrfs filesystem prop set . btrfs subvolume prop set . btrfs inode prop set . ? btrfs has already grouped the commands by category (even tough I have to admit that some command doesn't fit its group. Why do not use this instead of -t object type. If we need new type we could create it on demand... David suggested that it should also be possible to specify objects by their id/uuid/fsid. I like that idea, but would be happy if someone else could take over that part :) This proposal makes sense. For now, I've implemented two properties: 1. read-only. Usable on subvolumes to toggle the read-only flags. 2. label. I looked through btrfs to find good examples of things that could be moved to the new properties interface and the filesystem label looked like a good one. There are for sure more, but that is something for later (and maybe for someone else). I would suggest to move everthing that makes sense over to the props interface and mark the old interfaces as deprecated. Comments on this are welcome. What is the suppose goal/benefit/advantage to switch to a new interface ? Really, it is a true question. Patch version history: v1 Initial version. v2 - Removed the filesystem prefix and implemented it as new command group - Switched from the name[=value] form to the set/get name [value] form. - Removed patches Btrfs-progs: make filesystem_cmd_group non const and Btrfs-progs: move skip_prefix and prefixcmp to utils.c. They are not needed anymore due to the 'btrfs prop list' command. - Udjusted the subvol flags patch to be compatible to the Btrfs: use _IOR for BTRFS_IOC_SUBVOL_GETFLAGS patch. - Using -t type instead of type: prefix now. - Changes are based on feedback from Ilya and David. Alex. Alexander Block (3): Btrfs-progs: add BTRFS_IOC_SUBVOL_GET/SETFLAGS to ioctl.h Btrfs-progs: let get_label return the label instead of of printing it Btrfs-progs: introduce btrfs property subgroup Makefile |5 +- btrfs.c |1 + btrfslabel.c | 13 +- btrfslabel.h |4 +- cmds-filesystem.c | 14 +- cmds-property.c | 459 + commands.h|2 + ioctl.h |2 + props.c | 114 + props.h | 43 + Please update the man page too... This could help the process of creating a new interface. 10 files changed, 645 insertions(+), 12 deletions(-) create mode 100644 cmds-property.c create mode 100644 props.c create mode 100644 props.h -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 0/3] Btrfs-progs: introduce btrfs property subgroup
On Wed, Jun 27, 2012 at 7:41 PM, Goffredo Baroncelli kreij...@libero.it wrote: Hi Alexander, On 06/27/2012 03:16 PM, Alexander Block wrote: This patchset introduces the btrfs property subgroup. It is the result of a discussion we had on IRC. I tried to make the properties interface as generic and extensible as possible. Comments are welcome. Currently the command group looks like this: btrfs prop set [-t type] /path/to/object name value btrfs prop get [-t type] /path/to/object [name] (omitting name dumps all) btrfs prop list [-t type] /path/to/object (lists properties with description) The type is used to explicitly specify what type of object you mean. This is necessary in case the object+property combination is ambiguous. For example '/path/to/fs/root' could mean the root subvolume, the directory inode or the filesystem itself. Normally, btrfs-progs will try to detect the type automatically. Instead of using btrfs prop set -t filesystem btrfs prop set -t subvolume btrfs prop set -t inode what about btrfs filesystem prop set . btrfs subvolume prop set . btrfs inode prop set . ? Specifying the object type is not needed normally, so the form where the prop commands are in their own command group is normally shorter and easier to type. The type argument is really only needed for ambiguous properties. btrfs has already grouped the commands by category (even tough I have to admit that some command doesn't fit its group. Why do not use this instead of -t object type. If we need new type we could create it on demand... David suggested that it should also be possible to specify objects by their id/uuid/fsid. I like that idea, but would be happy if someone else could take over that part :) This proposal makes sense. For now, I've implemented two properties: 1. read-only. Usable on subvolumes to toggle the read-only flags. 2. label. I looked through btrfs to find good examples of things that could be moved to the new properties interface and the filesystem label looked like a good one. There are for sure more, but that is something for later (and maybe for someone else). I would suggest to move everthing that makes sense over to the props interface and mark the old interfaces as deprecated. Comments on this are welcome. What is the suppose goal/benefit/advantage to switch to a new interface ? Really, it is a true question. The reason is that there will come a lot more things that you can configure on an inode/subvolume/filesystem/device basis and we agreed that a generic interface for such configurations will be a good thing in the future. Patch version history: v1 Initial version. v2 - Removed the filesystem prefix and implemented it as new command group - Switched from the name[=value] form to the set/get name [value] form. - Removed patches Btrfs-progs: make filesystem_cmd_group non const and Btrfs-progs: move skip_prefix and prefixcmp to utils.c. They are not needed anymore due to the 'btrfs prop list' command. - Udjusted the subvol flags patch to be compatible to the Btrfs: use _IOR for BTRFS_IOC_SUBVOL_GETFLAGS patch. - Using -t type instead of type: prefix now. - Changes are based on feedback from Ilya and David. Alex. Alexander Block (3): Btrfs-progs: add BTRFS_IOC_SUBVOL_GET/SETFLAGS to ioctl.h Btrfs-progs: let get_label return the label instead of of printing it Btrfs-progs: introduce btrfs property subgroup Makefile | 5 +- btrfs.c | 1 + btrfslabel.c | 13 +- btrfslabel.h | 4 +- cmds-filesystem.c | 14 +- cmds-property.c | 459 + commands.h | 2 + ioctl.h | 2 + props.c | 114 + props.h | 43 + Please update the man page too... This could help the process of creating a new interface. 10 files changed, 645 insertions(+), 12 deletions(-) create mode 100644 cmds-property.c create mode 100644 props.c create mode 100644 props.h -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
