Also note that I have not had a chance to try devfs yet, so I really am
not fully qualified to argue about it, however...
On Fri, 7 Aug 1998, Theodore Y. Ts'o wrote:
<snip>
> Certainly, using volume labels is IMO far better than a silly name
> like c0s1d4t6 or whatever ---- first of all, the volume name has
> semantic meaning to the user,
But is next to worthless for automated scripts until someone enters
everything by hand..
> and secondly, it works even if you remove the JAZ cartridge from one
> drive and put it into another drive, since the name follows the
> filesystem, not the SCSI id.
What happens if you have two JAZ drives, and two duplicate cartrages?
Also, what does this do for us that DO have file systems not supported?
Your method still leaves us up the river..
And there is the issue of loading the module so you can find the root fs
when its on a SCSI drive in the middle of the search list, when you have
just pulled out the first one..
(Granted, this one is probley solvable by putting it in the kernel itself)
And, of course, what do you do for new stuff? Cross your fingers and pray
you can remember the SCSI boot order correctly?
<snip>
> Fundamentally, I disagree with Richard Gooch that persistence is a "side
> issue". Being able to assign groups and permissions is a fairly
> fundamental part of /dev, and how system administrators allow who's
> allowed to access a modem, a tape drive, a printer, etc.
I aggree with you there actualy...
However he seems /quite/ open to changing things if someone comes up with
something which is (IHO) a better answer, I'm sure persistence is one of
them...
> To make it an afterthought in the design is in my opinion a big
> mistake, and it's one of the reasons why I consider devfs a hack.
A mistake? Perhaps, but a fatal one? No, shoot, its been suggested that we
do it all in user space...
> Running tar on /devfs at shutdown time is at least ten times as ugly
> as indirecting through a lookup table for resolving major/minor devifs
> numbers. :-)
Glad you think so, now, expand major/minors to be 32 bit or so, well
maintaining binary compatabley, come up with a clean answer which people
will accept...
Now, compair how clean they are...
Zephaniah E, Hull....
> - Ted
-
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.altern.org/andrebalsa/doc/lkml-faq.html