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;
Date:   Tue, 10 May 2022 17:30:50 +0200
From:   Christian Brauner <brauner@kernel.org>
To:     Miklos Szeredi <miklos@szeredi.hu>
Cc:     linux-fsdevel@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
        Theodore Ts'o <tytso@mit.edu>, Karel Zak <kzak@redhat.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        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>,
        Amir Goldstein <amir73il@gmail.com>,
        James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [RFC PATCH] getting misc stats/attributes via xattr API
Message-ID: <20220510153050.cgbt3wezbvf2jfnb@wittgenstein>
References: <YnEeuw6fd1A8usjj@miu.piliscsaba.redhat.com>
 <20220509124815.vb7d2xj5idhb2wq6@wittgenstein>
 <CAJfpegveWaS5pR3O1c_7qLnaEDWwa8oi26x2v_CwDXB_sir1tg@mail.gmail.com>
 <20220510115316.acr6gl5ayqszada6@wittgenstein>
 <CAJfpegtVgyumJiFM_ujjuRTjg07vwOd4h9AT+mbh+n1Qn-LqqA@mail.gmail.com>
 <20220510141932.lth3bryefbl6ykny@wittgenstein>
 <CAJfpegt94fP-_eDAk=_C=24ahCtjQ4vhh8Xg+SrZbwPHs1waLA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAJfpegt94fP-_eDAk=_C=24ahCtjQ4vhh8Xg+SrZbwPHs1waLA@mail.gmail.com>
Precedence: bulk

On Tue, May 10, 2022 at 04:41:35PM +0200, Miklos Szeredi wrote:
> On Tue, 10 May 2022 at 16:19, Christian Brauner <brauner@kernel.org> wrote:
> 
> > Fwiw, turning this around: unifying semantically distinct interfaces
> > because of syntactical similarities is bad. Moving them into a
> > syntactically equivalent system call that expresses the difference in
> > semantics in its name is good.
> 
> You are ignoring the arguments against fragmentation.

No, I'm not ignoring it and really wasn't trying to. What I tried to say
by this, is that the inverse of the argument against fragmentation is
simply equally worth supporting. Meaning the argument against
fragmentation isn't stronger than the argument against aggressive
unification.

(Fwiw, I think that basing the argument on syntactical similarities is
problematic. Stretching this argument for a second, all multiplexers are
almost by necessity syntactically similar (e.g. ptrace() and seccomp())
but we don't use that as an argument to make them a single system call.)

> 
> You are also ignoring the fact that semantically the current xattr
> interface is already fragmented.   Grep for "strncmp(name, XATTR_" in
> fs/xattr.c.
> 
> We don't have getsecurityxattr(), getuserxattr(), gettrustedxattr()
> and getsystemxattr().  It would be crazy.   Adding getfsxattr()  would
> be equally crazy.  getxattr() pretty much describes the semantics of
> all of these things.

getxattr() describes the syntax of all of these things and barely that.
It describes the method of retrieval. And the method of retrieval is
super generic to the point where strings _or binary data_ can be
returned (e.g. POSIX ACLs or fscaps) depending on the xattr namespace.
But wight now, everything we currently get from getxattr() is attributes
associated with inodes.

So getsecurityxattr(), getuserxattr(), gettrustedxattr() etc. would
arguably be fragmentation because all of these things are associated
with inodes.

But now we're in the process of extending the *xattr() calls to operate
on mounts and filesystems so an additional getfsattr() (or another name)
is not fragmentation imho. And I definitely don't think this would
qualify as "crazy".