Peter Samuelson <peter@cadcamlab.org> said:
> [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 question was why devfsd was needed at all...
[...]
> > 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.
Or into /etc/devfsd.conf. Same thing.
> 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
In the case above I'm using extant mechanism (kmod has to stay for the
later one to work). For modules.conf I need the association major == 4 -->
serial; in devfsd.conf I need the association /dev/ttys/* --> serial. Same
thing, different syntax. But more mechanism, which is pure overhead as it
solves nothing and introduces new problems (non-persistence). Not just
bloat, ballast.
[...]
> 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.
Why are you then building all this crap on top of the parallel tree in the
first place?!
> 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.
devfsd, working on a on-disk device tree does solve the problems rather
nicely IMHO. devfs is a horrible kludge, and seeing Linus include that in
his tree makes me seriously doubt his taste this one time. And the devfsd
idea is Linus's, AFAIKT.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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