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/