Re: [PATCH 0/5] btrfs: send uevent on subvolume add/remove

[David Sterba]

On Wed, Oct 23, 2019 at 11:36:31PM -0300, Marcos Paulo de Souza wrote:
> From: Marcos Paulo de Souza <mpdesouza@xxxxxxxx>
> 
> 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.