True.
> - total system complexity goes up as you have a growing collection of
> daemons and scripts to do these new cool things
True.
> - you miss the efficiency of devfs
Efficiency of the device I can understand, but why would you need a
faster way to create a device node?
> - it makes it much easier to handle read-only or non-Unix root FSes.
But it makes it much harder to preserve uid/gid/perms across system
reboots. User space daemons neatly avoid this problem.
> Devfs is a single, simple framework that allows you to do do a whole
> raft of cool things without having to add a patch for each new trick.
> Devfs is extremely lightweight (about a few pages of code and a few
> pages of data on an average system). The pages you save by not having
> devfs you lose in having a bunch of clever daemons instead (we can't
> avoid paying for kernel stake space).
>
> Also, since this debate started because of talk about increasing
> device number size, let me point out that with devfs can save having
> to store the two tables of major numbers (chr and blk), which are
> going to grow somewhat. I admit that would require further changes,
> which I've avoided in order to have minimal impact.
>
> However, with devfs you can definately avoid the lookups into the
> major tables. Right now that's fast because they're simple arrays. If
> we go to 12 bit majors (or more), we're going to want to set them up
> as lists of some kind. And that means some kind of searching/hashing.
> And that's all for the benefit of finding our fops. Devfs completely
> avoids this overhead.
I suspect the issues some people raise aren't with the concept of a
dynamically changing /dev, but with the concept of a virtual /dev.
Also at least one person thinks that the idea is good but should be
done in user space, because the kernel doesn't need bloat.
I suspect that if you replaced your node creation code with code to
communicate to a user space daemon, and then that user space daemon
created the node instead, you'd garner more support.
As a side bonus you could then throw away the nasty hacks that save
the uid/gid/perms across system rebooots. All you'd lose is the NFS
diskless client and readonly root filesystem cases.
I also suspect that a user space "device manager" daemon would have
other uses as well, beyond the scope of devfs. For example, modules
could request that firmware be uploaded (not easily doable from the
kernel). Sound modules could get the daemon to set mixer levels and
run sound daemons like ESD. I am sure packages like pcmcia-cs could
benefit from an all encompassing device manager daemon, too.
At the moment devfs only deals with node creation/deletion. This is
great, but is it enough? A user space daemon lets you grow the idea
without bounds, and this might be more useful, especially with more
complex hotswap devices such as USB (which may not even require any
/dev entries).
--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au
-
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/