[enfs-devel] Configuration tools and thoughts on /proc

[Tramm H. <hu...@sw...>]

Folks,

Lee mentioned that there was an experimental procfs style interface
for configuring enfs.  I'd like to explore the possibilities that we
can do with such a system and try to gauge how long it would take to
implement some features:

- Module loading / unloading
- Namespace building
- Metadata presentation
- Per-module configuration and performance tuning
- Per-module output
- SWIG interface

-----

The first case is fairly easy.  Module lists can be presented in
a fashion similar to the /proc/modules file under Linux.  It lists
the module name, the size in bytes, the use count and other
modules that are using it.

The only complexity comes in relative file paths.  In a secure
environment enfs should run chrooted to nowhere, which could make
accessing the modules difficult.  There is unfortunately no form of
fd_dlopen() or the like.  We could read the module on an fd and
write it to a temp file, but then we lose the ability to let ld
do the hardwork of dependency management.

We can probably punt on the security issues, although that always
bothers me.  I have rarely seen any of those "later" items get fixed.

-----

The namespace building can be done by presenting the metadata tree
in this filesystem and implementing the link or symlink calls to
setup mount covers.  I think this would work and free the mount
call from dealing with the complexity of setting up and tracking
covers; we would just push the details elsewhere in the code base.
I'd like to whiteboard this sometime because there are probably
tricky details that need to be worked out.

-----

Statistics gathering is also easy.  We just need an easy way for
a module to create a file or tree in /proc and map datastructures
to it.  Providing some simple templates for char*, int, int[], char*[]
would be good.  This does require some namespace code, although
it could be in the proc module rather than the kernel.

I like Perl's tie mechanism, but it's a bit too difficult to map
into C very well.

Performance tuning is similar to statstics gathering in reverse.
If we have the above, then we can get parameters into modules
in the same manner.

-----

If we have a SWIG interface then modules can be written in a variety
of languages.  I think PerlFS would be cool, despite the legal
encumberances (cf Applesoft).  The other advantage of making a Perl
interface is that many of the Perl data structures map very easily
to filesystem trees.  When combined with the tie magic the code
could transparently make Perl hashes appear in the filesystem.
That's way cool.

-----

Lots of random ideas, folks.  With the exception of the module
loading, none of them are on the critical path to either of our
organizations' goals.  But most of them are things that I think we
need for ease of use should we start getting outside users.

Trammell
-- 
  o   hu...@sw...                                         O___|   
 /|\  http://www.swcp.com/~hudson/          M 240.476.1373    /\  \_  
 <<   KC5RNF                                H 505.315.5133    \ \/\_\  
  0                                                            U \_  |