On Fri, Apr 26 2019, J. Bruce Fields wrote: > On Fri, Apr 26, 2019 at 01:00:19PM +0200, Andreas Dilger wrote: >> >> On Apr 26, 2019, at 1:20 AM, NeilBrown wrote: >> > /proc/fs/nfsd is the (standard) mount point for a separate NFSD-specific >> > filesystem, originally created to replace the nfsd-specific systemcall. >> > So the nfsd developers have a fair degree of latitude as to what can go >> > in there. >> > >> > But I *don't* think it is a good idea to follow this pattern. Creating >> > a separate control filesystem for every different module that thinks it >> > has different needs doesn't scale well. We could end up with dozens of >> > tiny filesystems that all need to be mounted at just the right place. > > Aren't we already there? My laptop, Fedora 29 with everything pretty much > default: > > $ findmnt -n -oFSTYPE|sort|uniq -c > 1 autofs > 1 bpf > 11 cgroup > 1 cgroup2 > 1 configfs > 1 debugfs > 1 devpts > 1 devtmpfs > 3 ext4 > 1 fusectl > 1 fuse.gvfsd-fuse > 1 hugetlbfs > 1 mqueue > 1 proc > 1 pstore > 1 rpc_pipefs > 1 securityfs > 1 selinuxfs > 1 sysfs > 5 tmpfs Sometimes I think "Linux is so full of crap, it hardly matters if more crap is added". Other times I feel a bit more social responsibility and want to fight against adding too much more crap. > >> > I don't think that is healthy for Linus. ^^^^^ oops > > What are the problems you see? Fragmentation. This is exactly the platform problem. People look at the existing functionality, decide that it doesn't quite meet their needs, and then do an implement something that is mostly the same but just different enough so that they feel more comfortable. We have 'seq_file' which encourages people to create line-oriented info files, but if some have tab-separate lines, others have CSV, others have yaml etc, then there is plenty of room for confusion. If we could, instead, just agreed that more structured data actually can make sense in sysfs, and come up with a coherent approach that we can all tolerate, then life would be much easier. > >> > Nor do I think we should be stuffing stuff into debugfs that isn't >> > really for debugging. That isn't healthy either. >> > >> > If sysfs doesn't meet our needs, then we need to raise that in >> > appropriate fora and present a clear case and try to build consensus - >> > because if we see a problem, then it is likely that others do to. >> >> I definitely *do* see the restrictions sysfs as being a problem, and I'd >> guess NFS developers thought the same, > > For what it's worth, the nfsd filesystem predated sysfs, just barely. > > Looking at the history.... It was actually Al that introduced it in March > 2002. Patrick Mochel added sysfs in October 2002. IIRC the nfsd filesystem was added to address the difficulty of supporting a systemcall in a module. That basically doesn't work, so there needed to be some clean interface between some minimal nfsdctl systemcall code that was always compiled in, and the actually implementation that could be in a module. It was Viro who particularly noticed this need, so it was a filesystem that was chosen to fill the need - filesystems in modules was already a solved problem. The system call was (I think) write-only (no non-trivial return data) and each file just recieved a binary struct that matches the syscall argument. Once that was in place, it became a dumping ground for whatever we wanted. sysfs was, I think, originally about power management. It exposed connections between devices more than the devices themselves. This allowed user-space to be able to power-things down when not in use, and to understand the dependencies. Since then it grew.... > > But it's true that from the start nfsd didn't really fit the model of a single > (possibly writeable) attribute per file. Depends on what you mean by that. Original files where write-only and where slightly complex attributes. Writing performed an action, like adding an entry to the export table (first you add a client, then add a client+filesystem to export it). This idea for a file performing an action, rather than presenting an attribute, is much the same as the "bind" and "unbind" files you can find in sysfs. (see also https://lwn.net/Articles/378884/ for examples of sysfs files that are not one-attribute-per-file) NeilBrown > > (Might be interesting to look at the distribution of new filesystem types over > time, there may have been a peak around then.) > > --b.