[9fans] Rest of the world waking up to filesystem based name models?

[ggm@apnic.net]

 From LWN, on some hubristical ottowa kernel summit

http://lwn.net/Articles/3327/

-----------
	:
	:

The other approach was presented by Patrick Mochel. As part of his ongoing
driver model work, he implemented "driverfs," the driver filesystem. driverfs
is a virtual filesystem initially developed as a debugging tool; it is a
convenient way of looking at the structure of the device tree. The facilities
provided by driverfs are similar to those provided by Rusty's scheme;
driverfs, too, is type-safe and easy to set up. It is also, for now, limited
to device drivers only; the question is whether it should be expanded to
handle kernel parameters in general.

While no conclusions were drawn in the session, driverfs looks (to your
author) like it is here to stay, since it so nicely incorporates the system's
structure in the filesystem it creates. It just needs to be expanded to cover
all of the other types of parameters in the system (i.e. VM, networking, etc.)
that are not directly associated with devices. A merger with some variant
Rusty's scheme would help in that regard, and seems likely at some point.

Linus pointed out that he would like to see a single, integrated filesystem
that includes all such information. Thus, for example, the "fsfs" that
provides filesystem information can include links to the underlying devices
holding those filesystems. Module information can link to the associated
driver and devices. Such a filesystem, he said, makes the linkages in the
system visible and explicit.

Eventually, /proc could be phased out in favor of a driverfs-like system, with
a "one file, one value" rule. This change really has to begin in 2.5, since
/proc has to be supported for at least one more stable kernel cycle. Expect to
see more activity in this area in the near future.

	:
	: