Messages in this thread | | | Date | Wed, 9 Jun 1999 13:32:18 +1000 | From | Richard Gooch <> | Subject | Re: Devfs, was Re: Migrating to larger numbers |
| |
Nathan Hand writes: > On Wed, Jun 09, 1999 at 11:26:07AM +1000, Richard Gooch wrote: > > - 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?
Efficiency of opening, clearly. Efficiency of creating device nodes, also. That's probably not a significant problem, but it may be if you have large numbers of devices. Remember that waking up a user space daemon which in turn frobs the FS is not a lightweight activity. Like I said, probably not a big deal, but something to bear in mind.
> > - 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.
Once devfsd has persistence support, this will go away. Note that already devfsd can be used to control uid/gid/perms. And it can do it in a way that is far more space efficient than a regular FS, because a whole group of devices can be modified with a single config entry.
> > 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.
To avoid the major table indexing/searching, there is no alternative but a virtual /dev. It can't be done with user space managing /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.
Not bloat. A few pages or so. Cheaper than user space-based solutions, is my guess.
> 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.
And miss the benefits of a virtual /dev.
> 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 agree that the current use of tar isn't that nice. It's not terribly ugly either. And it's easy to solve in devfsd in a nice way.
> 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.
You're talking about devfsd. Already exists. There's a lot you can do with it already.
> 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).
Devfsd. Check it out.
Regards,
Richard....
- 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/
| |