[Horst von Brand <vonbrand@sleipnir.valparaiso.cl>]
> No. How do you load a module for /dev/foo117, when /dev/foo117
> doesn't currently exist?
Actually with devfs it's really easy. If user space tries to open
/dev/foo117, and it doesn't already exist, this will generate a devfsd
event. Then devfsd can look in its config file and call modprobe.
(The only place this breaks down is if userspace is relying on
readdir() to tell it what to open. But this is pretty broken in the
non-devfs case too. You're just asking for -ENODEV.)
Formerly Richard had devfs calling request_module() directly on the
requested pathname. He took that out when devfsd acquired the
necessary functionality.
> This is elegantly solved in the traditional case with just a device
> file created before use, major/minor (more generally, device id) tell
> the kernel what module to ask for.
You forgot the part about encoding the major (and possibly minor)
numbers into /etc/modules.conf.
Here's the real difference. Say you compile serial.o as a module:
# modules.conf: if we get a request for a character device on major
# number 4, have modprobe load serial.o
alias char-major-4 serial
# devfsd.conf: if someone tries to stat or open /dev/tts or
# /dev/tts/*, have devfsd run modprobe to load serial.o
LOOKUP tts EXECUTE modprobe -k serial
The first requires (a) kmod support and (b) you have to know the magic
number 4.
The second requires (a) devfs support and (b) you have to know the
magic name "tts".
> You can then also painlessly set (and preserve) permissions on the
> device in the filessytem. Cost is one inode on disk per device.
Wait -- don't chown/chmod/mknod also generate devfsd events? Why can't
devfsd take those events and operate on a parallel directory tree? And
then use that parallel tree to chmod/chown next time the device inserts
itself, i.e. after insmod or reboot. (Remember, devfsd is notified on
every file creation, if it cares.) No tar kludge involved.
I could have sworn this was Richard's idea, not mine. devfsd, properly
implemented, can solve a *lot* of these problems. If the current
devfsd is a WIP, don't blame it on devfs design problems.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:21 EST