archive mirror
 help / color / mirror / Atom feed
From: David Sterba <>
To: Marcos Paulo de Souza <>
Subject: Re: [PATCH 0/5] btrfs: send uevent on subvolume add/remove
Date: Mon, 18 Nov 2019 21:50:13 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

      parent reply	other threads:[~2019-11-18 20:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24  2:36 [PATCH 0/5] btrfs: send uevent on subvolume add/remove Marcos Paulo de Souza
2019-10-24  2:36 ` [PATCH 1/5] btrfs: sysfs: Add envp argument to btrfs_kobject_uevent Marcos Paulo de Souza
2019-10-24  2:36 ` [PATCH 2/5] btrfs: ioctl: Introduce btrfs_vol_uevent Marcos Paulo de Souza
2019-10-24  2:36 ` [PATCH 3/5] btrfs: ioctl: Call btrfs_vol_uevent on subvol creation Marcos Paulo de Souza
2019-10-24  2:36 ` [PATCH 4/5] btrfs: ctree.h: Add btrfs_is_snapshot function Marcos Paulo de Souza
2019-10-25 10:02   ` Filipe Manana
2019-10-24  2:36 ` [PATCH 5/5] btrfs: ioctl: Call btrfs_vol_uevent on subvolume deletion Marcos Paulo de Souza
2019-10-25 12:00   ` Graham Cobb
2019-10-25 15:44     ` Marcos Paulo de Souza
2019-11-18 20:50 ` David Sterba [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).