I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
I will not get draw into another devfs flamewar.
Sh*t.
[Peter Samuelson]
> > 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.
[Alexander Viro]
> Funny, that... Where did I hear about something similar? Ah, yes.
> automounter. Somebody, tell Richard that Sun had stolen his idea many
> moons ago...
I can't speak for Richard of course, but I honestly had never thought
of (ab)using autofs for device nodes. If it's been mentioned here
before, it must have been when I wasn't reading l-k. Certainly the
autofs protocol could provide at least some of the functionality of the
devfsd protocol.
> BTW, _what_ was that wrong with using autofs for that instead of
> reinventing the wheel?
Perhaps because adding a devfsd mechanism to devfs is more lightweight
on the kernel side. fs/autofs/ is 68 blocks on my box, fs/devfs/ is
just under twice that. I know obj side != source size, but I'd guess a
lot less than half of devfs is devoted to the devfsd protocol....
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