Subject: Re: Getting rid of /dev/veriexec
To: Rui Paulo <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 12/03/2005 13:24:48
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 firstname.lastname@example.org
"The inconsistency is startling, though admittedly, if consistency is to be
abandoned or transcended, there is no problem." - Noam Chomsky