The following patch replaces devfs with a ramfs-derived
implementation which is under one quarter the size although it
eliminates certain functionality.
wc -l *.c Makefile size (text + data + bss)
devfs 3614 lines 25,863 bytes
mini-devfs 629 lines 5,367 bytes
Reduction 5.7x 4.8x
Further minor reductions may be possible from some additional
clean-ups and perhaps a simplification to the programming interface.
This code is probably very buggy. I've just gotten it working
on the machine on which I'm composing this message. It is not ready
for integration yet. I would particularly appreciate help with the
dentry manipulation and locking, which I think I've probably botched.
The notable differences between devfs and mini-devfs are:
1. devfsd has been replaced with the user mode helper
/sbin/devfs_helper which is exec'ed for registration and initial
lookup events (I could catch all the events that devfs does, but I
don't think that's really necessary). I have yet to port devfsd to
this interface. When sysfs support is added to the new kernel
parameter system, I will make this a kernel parameter, so it can be
off initially, and only turned on by systems that use it when the boot
process is ready for it. This will also eliminate the problem where
the boot process currently tries to do 200+ execs as each pseudo-terminal
is registered.
2. The removable device code that cleared and reread partition
tables from removable media all the time preventing use of userland
partitioning with devfs is eliminated. (Non-devfs systems never had
this problem.)
3. devfs_handle_t is now a synonym for struct dentry*.
4. A lot of the devfs routines are unimplemented. I haven't
noticed much code that uses them, and I'm not sure that any code
really should. I think arch/ia64/sn uses devfs_get_first_child,
devfs_get_next_sibling. I need to understand what if any of the
other routines are really necessary and why (for example, why can't
we use struct dentry). My computer seems to run fine without them.
TODO:
First of all, I'd like to debug this code and I'd welcome any
help. The only malfunction (aside from routines that aren't written)
that I've noticed is that previously xdm would give up after trying to
start the X server about five times (it is not configured). With this
smaller devfs, xdm keeps trying to start the X server. Also, I'm
pretty sure that my code is at least releasing and reacquiring
dcache_lock when it shouldn't, and I think there may be some similar
inode->i_sem issues.
In the future, I'd like to shrink the devfs interface to
devfs_{create,delete}. If we prohibit file renaming in devfs, then
drivers can be sure they've removed the devfs nodes that they've
created when they delete the paths that they've created. A
side-effect of this would be that devfs_handle_t would be eliminated.
I still want the ability to pass a struct file_operations* to
devfs_create as it may enable the elimination of fixed device numbers.
I think I'd like to change fs/super.c slightly to make it
easier to statically allocate the struct super_block for filesystems
that can have only one instance even if they are mounted in multiple
locations (devfs, procfs, sysfs, usbdevfs, etc.).
I started hacking on this code by making an approximately ten
line change to ramfs just to have it call a user level program on
lookups and file creation. I had hoped to change the devfs routines
to just generically operate on whatever was mounted on /dev. If
the devfs API were shrunk substantially, it might be worth trying
that approach again.
Comments?
--
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:20 EST