> > /dev/sd_h0c0t0u0p2 OR:
> > /dev/disc/sd_h0c0t0u0p2
>
> how about /dev/dsk/h0c0t0u0p2? lose the sd_. it doesn't buy you anything.
> ide drives are done differently anyways.
Actually, my favorite scheme among those discussed here grouped the
devices by function, irrespective of controller type. E.g:
/dev/disk/sd_blah
/dev/disk/hd_blah (or ide_blah?)
/dev/tape/sd_blah
/dev/tape/hd_blah
etc.
So that it would be obvious from a directory listing both what the device
does (disk/tape/scanner/etc), what interface it uses (sd/hd) and where on
that interface it is located (partition/scsi ID/whatever, encoded into the
'blah' part of my examples).
I am personally a proponent of the shallow (but nested) directory
structure. One, at most two, sublevels, keeping the top level as clean as
possible (who wants ptyBLAH cluttering up /dev?). The top level can also
contain compatability links for new user migration -- i.e. /dev/hda still
works until you change the fstab over to /dev/disk/whatever and recompile
with CONFIG_DEVFS_COMPAT turned off, or whatever.
Just my two cents. =)
--Scott
@ @
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-oOO-(_)-OOo-=-=-=-=-=
C. Scott Ananian: cananian@lcs.mit.edu / Declare the Truth boldly and
Laboratory for Computer Science/Crypto / without hindrance.
Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31
-.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -.
PGP key available via finger and from http://www.pdos.lcs.mit.edu/~cananian