Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3300279ybc; Mon, 18 Nov 2019 12:52:56 -0800 (PST) X-Google-Smtp-Source: APXvYqxgYHRUkeRH/onoMAk2Te3BISc/3PPi0xV4Fe8vbclAMqIGY2a6JH+JkrLb9WqZ3CXjVTvP X-Received: by 2002:a17:906:c797:: with SMTP id cw23mr28758810ejb.19.1574110376328; Mon, 18 Nov 2019 12:52:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574110376; cv=none; d=google.com; s=arc-20160816; b=mlwYTvM6nERdUfDoQw84PCAYBrs7ofYLjGlHpoZE+xlDn21pLL9Gm+d3r4nSdywe7y C7sg8ozxWDgrJ8GiDdnr4bglwG2kKoIrrlCisJJBkjw96IjS5MpJdHvdXLC7W38v1Sqp QIDFfmCmyw5JQDNEPxq+59wsJPZC5IuZjr2aCgA1cYtwN8PAj6PqojN8nI4ybXszntSF /ocM55uCTLG5/qSxBg8N4CRd2Xz4J9k+4hBP/QefIfD/0PfJJjfyFBRS8Rc2hqbd8HLi k0f/DKz8goiayy66fw5GAen1GXEXZvUI2duEP4FT1Bnxxzd6txokNmeXHqnslExlTMnT dCSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :reply-to:message-id:subject:cc:to:from:date; bh=I12ESO7/WMvmtyMIJ4630lyb8Jb7Fjgwx7hJHTqc7HA=; b=nwwLg8J+oBmVOOhiR01kfQqY9siZHISnQ9yWCJzOe70mxopxWCm3kc/nqhaLorlQAp zFPIb5y+znM3fqdXU07nZnbKsw87kOWoDzqnHlVRbkBOHHy/TxkwUELh2ka3xO/BmLZx Tt2uhoxoMG3lRerg2DrrrfkgrezHFElIywBSuB/tMzDdlho6DWIGKkwUyHZGE2HYSiSP M7U7Rh0Bb19nIsEO7g6O4/IbIgjUKXRhVQJ9T5nnZjrz5uY/OxFH1mAuoX8gtQQM82ke bcghHtq1ATPnBIfqwzK1Wyd2mmC0i/Nsqtnb+pjFl8PZpvh8/u79AohfxnNElWkMSvyL mauw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t26si13194342edc.102.2019.11.18.12.52.32; Mon, 18 Nov 2019 12:52:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726962AbfKRUuO (ORCPT + 99 others); Mon, 18 Nov 2019 15:50:14 -0500 Received: from mx2.suse.de ([195.135.220.15]:49058 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726666AbfKRUuO (ORCPT ); Mon, 18 Nov 2019 15:50:14 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 82BF9B13D; Mon, 18 Nov 2019 20:50:12 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id E9A08DAB3A; Mon, 18 Nov 2019 21:50:13 +0100 (CET) Date: Mon, 18 Nov 2019 21:50:13 +0100 From: David Sterba To: Marcos Paulo de Souza Cc: linux-kernel@vger.kernel.org, clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, mpdesouza@suse.com Subject: Re: [PATCH 0/5] btrfs: send uevent on subvolume add/remove Message-ID: <20191118205013.GO3001@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Marcos Paulo de Souza , linux-kernel@vger.kernel.org, clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, mpdesouza@suse.com References: <20191024023636.21124-1-marcos.souza.org@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191024023636.21124-1-marcos.souza.org@gmail.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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.