Subject: Re: /dev/cuaXX & other things
To: Tobias Weingartner <weingart@austin.BrandonU.CA>
From: VaX#n8 <firstname.lastname@example.org>
Date: 12/21/1994 00:58:36
While really really bored, Tobias Weingartner wrote:
> To jump on the bandwagon, I think locking should be done in the kernel,
> unless you can think of a way to lock things in userland, and not have to
> worry about lockfiles, etc...
Lockfiles are icky, I agree. A library of standard lock procs would mitigate
this somewhat. I hate writing the code a bazillion times. Driver locks are
good too :)
> One thing I do worry about, is the haphazard way that devices are named
> in the /dev directory. Can we clean this up some? Please?
I'm not sure about really long names, but some dev files need a little touchup.
I use tape devices every week or so, but my brain still reads "nrst0" as
"no-rewind ess-tee-zero". I -know- what it means, it's just tough to associate
it all. I like the fact that it is -mostly- self-consistent, I just wish it
were more so. Perhaps there should be an order to the letters... required ones
first, optionals follow, so -all- raw devices start with r, etc.
And I still haven't learned the console/vga/tty thing. :-/
However, there's probably too much code inertia behind the current letterings.
Just looking at the slip/network code (some of which assumes /dev/ttyXX format)
can make you not want to change anything.
Bottom line, I suppose, is that there needs to be a global namespace, but
should it be for the code's use (cryptic but stable) or for documentation?
I say as long as it's old drivers, stick with tradition, but if it's something
new, /dev/speaker is descriptive enough for me :)
I'm going to meander a bit and wonder aloud if it's better to use short names
as the standard (ex: "ls") and force newbies to learn them, or use long ones
as the standard, and force experts to lug around alias files everywhere (which,
admittedly, they usually do anyway). But I suppose this is way off topic.
VaX#n8 (vak-sa-nate) - n, CS senior++ and Unix junkie - email@example.com
Just the vax-man. Read my MIPS, no new VAXes! - PGP key on request