Re: Switching from IOCTLs to a RAMFS

[Jeff Garzik <jgarzik@pobox.com>]

Mark Peloquin wrote:
> Based on the feedback and comments regarding
> the use of IOCTLs in EVMS, we are switching to
> the more preferred method of using a ram based
> fs. Since we are going through this effort, I
> would like to get it right now, rather than
> having to switch to another ramfs system later
> on. The question I have is:  should we roll our
> own fs, (a.k.a. evmsfs) or should we use sysfs
> for this purpose? My initial thoughts are that
> sysfs should be used. However, recent discussions
> about device mapper have suggested a custom ramfs.
> Which is the *best* choice?


(cc'd viro and mochel, as I feel they are 'owners' in the subject area)

Let's jump back a bit, for a second.  Why is procfs bad news?  There are 
minor issues with the implementation of single-page output and lack of 
pure file operations, but the big issue is lack of a sane namespace. 
sysfs is no better than procfs if we keep heaving junk into it without 
thinking about proper namespace organization.

I personally prefer a separate filesystem for what you describe.  That 
gives the EVMS team control over their own portion of the namespace, 
while giving complete flexibility.  I do _not_ see sysfs as simply a 
procfs replacement -- sysfs IMO is more intended as a way to organize 
certain events and export internal kernel structure.

To tangent a bit, WRT a private evmsfs, make sure that (a) you prefer 
ASCII over binary interfaces where reasonable, and (b) any binary 
interfaces you have are fixed-endian and 64-bit safe from the get-go. 
Consider crazy cases like someone exporting evmsfs over NFS, from a 
32-bit IA32 server to a big-endian 64-bit client.

	Jeff