Messages in this thread | | | Date | Tue, 13 Jan 1998 05:23:59 -0500 (EST) | From | "C. Scott Ananian" <> | Subject | Re: devfs |
| |
On Tue, 13 Jan 1998 Jauder Ho <jauderho@transmeta.com> wrote:
> > /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
| |