On Sat, Dec 03, 2005 at 09:38:40AM +0000, Rui Paulo wrote:
> On 2005.12.02 11:06:24 -0500, der Mouse wrote:
> | 
> | It is.  sysctl is.  I've often considered building a sysctlfs, which
> | would present the sysctl hierarchy and data in a filesystem form.
> 
> I suppose we had the same idea :-)

I agree that it is a good idea to keep this stuff within the filesystem
namespace.  I do not, however, think that we should use normal filesystem
system calls to access the data.

I have some painful experience with coherency issues between the kernel,
userspace, and multiple processes in kernfs on Linux and I do *not* want
to go there again.  Moreover, I think that if we use a bytestream as the
abstraction for the contents of these "files" we will inevitably expose
ourselves to a number of the problems we've had with kmem and other bulk
data grovellers in /dev.

To me, a hybrid approach where we keep the best parts of sysctl -- the
type-specific accessors, the hierarchical naming scheme, and the ability
for nodes to dynamically appear and disappear (not possible in an on-disk
/dev) -- while also using the best parts of the filesystem: the single
namespace, access control by owner and permissions -- would be ideal.  A
sysctlfs could implement this by having the nodes appear in the filesystem
namespace but failing all unstructured I/O system calls: the file
descriptors from this FS would be valid _only_ for access calls much like
the ones we use for sysctl now.

This would also avoid the "every dispenser of structured data in /dev uses
its own hand-rolled ioctl routine" issue, which would be nice.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com

"The inconsistency is startling, though admittedly, if consistency is to be
 abandoned or transcended, there is no problem."		- Noam Chomsky