| Message ID | 20191024023636.21124-1-marcos.souza.org@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | btrfs: send uevent on subvolume add/remove | expand |
On Wed, Oct 23, 2019 at 11:36:31PM -0300, Marcos Paulo de Souza wrote: > From: Marcos Paulo de Souza <mpdesouza@suse.com> > > Hey guys, > > these patches make btrfs to send an uevent to userspace whenever a subvolume is > added/removed. The changes are pretty straightforward. This patchset was based > in btrfs-misc-next. > > The first patch adds an additional argument to btrfs_kobject_uevent to receive a > envp, and just forward this argument to kobject_uevent_envp. For the reference, this is from the project ideas on wiki https://btrfs.wiki.kernel.org/index.php/Project_ideas#Send_notifications_about_important_events There are 2 parts, the "transport" and the events. The device uevents mechanism is the transport, so all we need here is to extend the environment pointer with the data. AFAICS, this itself builds on netlink so there are more possible consumers of the events, namely not just udev and the like. The events is more high-level thing and the wiki lists some of them. You picked the subvolume creation/deletion, which is fine for demonstration and prototyping. Right now the details of the events need to be defined. > Patch number 2 creates a new function that will be called by patches 4 and 5 to > setup the environment variable to be set to userspace using uevent. These two > environment variables are BTRFS_VOL_{NEW,DEL} and BTRFS_VOL_NAME. The first > variable will have the value 1 for subvolume add/remove (only one will be > exported, so udev can distinguish the event), and the second one hold the name > of the subvolume being added/removed. > > Feel free to suggest any other useful information to be exported to userspace > when adding/removing a subvolume. The filesystem id needs to be there, maybe for all events. For the subvolume in particular there can be the id, parent id and flags. We need to see and forsee all the events and identify the common event data, or for same group events (like device manipulation) and decide if we go specific event "types" for each action. I think something that follows the naming and granularity of ioctls would be least confusing. So for subvolumes we can start with SUBVOLUME_CREATE and SUBVOLUME_DESTROY.
From: Marcos Paulo de Souza <mpdesouza@suse.com> Hey guys, these patches make btrfs to send an uevent to userspace whenever a subvolume is added/removed. The changes are pretty straightforward. This patchset was based in btrfs-misc-next. The first patch adds an additional argument to btrfs_kobject_uevent to receive a envp, and just forward this argument to kobject_uevent_envp. Patch number 2 creates a new function that will be called by patches 4 and 5 to setup the environment variable to be set to userspace using uevent. These two environment variables are BTRFS_VOL_{NEW,DEL} and BTRFS_VOL_NAME. The first variable will have the value 1 for subvolume add/remove (only one will be exported, so udev can distinguish the event), and the second one hold the name of the subvolume being added/removed. Feel free to suggest any other useful information to be exported to userspace when adding/removing a subvolume. Patches 3 and 5 call btrfs_vol_uevent to send the event on subvolume add/remove. Patch 4 creates a helper function to distinguish a subvolume from a snapshot, since the same function is used to delete both. This function is used in patch 5. Thanks for you reviews! Marcos Paulo de Souza (5): btrfs: sysfs: Add envp argument to btrfs_kobject_uevent btrfs: ioctl: Introduce btrfs_vol_uevent btrfs: ioctl: Call btrfs_vol_uevent on subvol creation btrfs: ctree.h: Add btrfs_is_snapshot function btrfs: ioctl: Call btrfs_vol_uevent on subvolume deletion fs/btrfs/ctree.h | 14 ++++++++++++++ fs/btrfs/ioctl.c | 39 ++++++++++++++++++++++++++++++++++++++- fs/btrfs/sysfs.c | 7 +++++-- fs/btrfs/sysfs.h | 3 ++- fs/btrfs/volumes.c | 2 +- 5 files changed, 60 insertions(+), 5 deletions(-)