Thread (88 messages) 88 messages, 14 authors, 2020-08-21

Re: [GIT PULL] Filesystem Information

From: Ian Kent <raven@themaw.net>
Date: 2020-08-05 20:14:29
Also in: linux-fsdevel, linux-security-module, lkml

On Wed, 2020-08-05 at 10:00 +0200, Miklos Szeredi wrote:
On Wed, Aug 5, 2020 at 3:33 AM Ian Kent [off-list ref] wrote:
quoted
On Tue, 2020-08-04 at 16:36 +0200, Miklos Szeredi wrote:
quoted
And notice how similar the above interface is to getxattr(), or
the
proposed readfile().  Where has the "everything is  a file"
philosophy
gone?
Maybe, but that philosophy (in a roundabout way) is what's resulted
in some of the problems we now have. Granted it's blind application
of that philosophy rather than the philosophy itself but that is
what happens.
Agree.   What people don't seem to realize, even though there are
blindingly obvious examples, that binary interfaces like the proposed
fsinfo(2) syscall can also result in a multitude of problems at the
same time as solving some others.

There's no magic solution in API design,  it's not balck and white.
We just need to strive for a good enough solution.  The problem seems
to be that trying to discuss the merits of other approaches seems to
hit a brick wall.  We just see repeated pull requests from David,
without any real discussion of the proposed alternatives.
quoted
I get that your comments are driven by the way that philosophy
should
be applied which is more of a "if it works best doing it that way
then
do it that way, and that's usually a file".

In this case there is a logical division of various types of file
system information and the underlying suggestion is maybe it's time
to move away from the "everything is a file" hard and fast rule,
and get rid of some of the problems that have resulted from it.

The notifications is an example, yes, the delivery mechanism is
a "file" but the design of the queueing mechanism makes a lot of
sense for the throughput that's going to be needed as time marches
on. Then there's different sub-systems each with unique information
that needs to be deliverable some other way because delivering
"all"
the information via the notification would be just plain wrong so
a multi-faceted information delivery mechanism makes the most
sense to allow specific targeted retrieval of individual items of
information.

But that also supposes your at least open to the idea that "maybe
not everything should be a file".
Sure.  I've learned pragmatism, although idealist at heart.  And I'm
not saying all API's from David are shit.  statx(2) is doing fine.
It's a simple binary interface that does its job well.   Compare the
header files for statx and fsinfo, though, and maybe you'll see what
I'm getting at...
Yeah, but I'm biased so not much joy there ... ;)

Ian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help