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 - vax@ccwf.cc.utexas.edu
Just the vax-man.  Read my MIPS, no new VAXes!        - PGP key on request