Richard Gooch wrote:
> Theodore Y. Ts'o writes:
>> Well, no, that doesn't work, since there plenty of non-process stuff
>> which doesn't fit into a devfs mounted in /dev.
>
> Such as?
/proc/mounts ?
> Explain to me how this is different from mounting devfs onto /kernel
> and using devfsd to populate a disc-based /dev.
I think Ted disagrees with devfs making choices like lumping all the,
say, IDE CD drivers together, instead of separating them by IDE bus.
I guess the real question is whether classifying things by their
purpose (e.g. "disk") instead of their attachment (e.g. ide0/master or
isa/busmouse) adds any significant complexity or ambiguity. I think in
almost every case the classification is already done elsewhere, so it
probably isn't too much of a problem.
> But this is a straw-man argument, because it ignores the persistence
> problem with a dynamic disc-based /dev which is managed with a user
> space daemon. This is a problem that's been overlooked.
Actually, with devfsd, wouldn't it be easier to have a configuration
file with a set of rules, a bit like what /dev/MAKEDEV has, but perhaps
more like a set of chmods executed in sequence, so that you can have
layered defaults ? E.g.
perm root sys 600 * */* */*/*
perm root sys 666 null zero full
perm root disk 660 */disk/*
...
Then simply refuse any direct chown/chmod by the user. Once people are
used to it, they may actually like it better.
Sorry if I'm re-iterating some thread long ago burried.
> Again I'll ask the question I've already asked a number of times. How
> would you cleanly support a construct like this:
> opendir ("/dev/ide/cd");
> loop;
Although you bring this up in almost every posting in devfs, I'm not so
sure if this is really an essential feature. It's nice, though.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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/