Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <YnEeuw6fd1A8usjj@miu.piliscsaba.redhat.com> <20220503224305.GF1360180@dread.disaster.area>
 <CAJfpegt_p2Tg+Tr34PtKSXvTyTJdTTwALMPRVE8KK2NmNVZhEg@mail.gmail.com>
In-Reply-To: <CAJfpegt_p2Tg+Tr34PtKSXvTyTJdTTwALMPRVE8KK2NmNVZhEg@mail.gmail.com>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Wed, 4 May 2022 17:22:37 +0300
Message-ID: <CAOQ4uxhALMgZeFHpPhu8oshrBzBjHcV-vTpFO=b-MeQ3OsQ6Ug@mail.gmail.com>
Subject: Re: [RFC PATCH] getting misc stats/attributes via xattr API
To:     Miklos Szeredi <miklos@szeredi.hu>
Cc:     Dave Chinner <david@fromorbit.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        "Theodore Ts'o" <tytso@mit.edu>, Karel Zak <kzak@redhat.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Christian Brauner <brauner@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Linux API <linux-api@vger.kernel.org>,
        linux-man <linux-man@vger.kernel.org>,
        LSM <linux-security-module@vger.kernel.org>,
        Ian Kent <raven@themaw.net>,
        David Howells <dhowells@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <christian@brauner.io>,
        James Bottomley <James.Bottomley@hansenpartnership.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, May 4, 2022 at 10:18 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Wed, 4 May 2022 at 00:43, Dave Chinner <david@fromorbit.com> wrote:
>
> > "values" is a very generic name - probably should end up being
> > something more descriptive of the functionality is provides,
> > especially if the header file is going to be dumped in
> > include/linux/. I don't really have a good suggestion at the moment,
> > though.
>
> The obvious ones are stat and attr, which are taken already.   Info is
> probably too generic as well.
>
> Ideas are welcome.

I was thinking of "properties".

>
> >
> > ....
> >
> > > +
> > > +enum {
> > > +     VAL_MNT_INFO,
> > > +};
> > > +
> > > +static struct val_desc val_mnt_group[] = {
> > > +     { VD_NAME("info"),              .idx = VAL_MNT_INFO             },
> > > +     { }
> > > +};
> > ....
> > > +
> > > +
> > > +static struct val_desc val_toplevel_group[] = {
> > > +     { VD_NAME("mnt:"),      .get = val_mnt_get,     },
> > > +     { VD_NAME("mntns:"),    .get = val_mntns_get,   },
> > > +     { },
> > > +};
> >
> > I know this is an early POC, my main question is how do you
> > envisiage this table driven structure being extended down from just
> > the mount into the filesystem so we can expose filesystem specific
> > information that isn't covered by generic interfaces like statx?
>
> I was thinking of adding a i_op callback.   The details are a bit
> fuzzy, since the vfs and the fs would have to work together when
> listing the attributes and possibly also when retrieving the attribute
> itself (think mount options).
>

No, please do not think mount options :)
Please think of an interface that does not mix vfs and fs properties.

Sure, with mount(2) you can mix fs and vfs options, but with the new interface
they should be clearly separated for set and get if possible.

":mnt:info" key to get the effective mount options (as in /proc/$$/mountinfo)
does not contradict that, because it can be read only.

Thanks,
Amir.