On Wed, 2020-08-05 at 10:00 +0200, Miklos Szeredi wrote: > On Wed, Aug 5, 2020 at 3:33 AM Ian Kent <raven@xxxxxxxxxx> wrote: > > On Tue, 2020-08-04 at 16:36 +0200, Miklos Szeredi wrote: > > > 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. > > > 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
