Messages in this thread | | | Date | Wed, 9 Jun 1999 13:19:30 +1000 | From | Nathan Hand <> | Subject | Re: Devfs, was Re: Migrating to larger numbers |
| |
On Wed, Jun 09, 1999 at 11:26:07AM +1000, Richard Gooch wrote: > Alan Cox writes: > > > > I just wonder if this shouldnt be generated by userspace, by > > ensuring the right helpful info is in /proc etc > > Yeah, I keep hearing arguments along this line. I don't think they > hold up, though, because: > > - for each cool thing you add another hack to the kernel to support it > (OK, not always, but the trend is there)
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/
| |