on 2/6/01 11:09 PM, Chuck McManis at cmcmanis@mcmanis.com wrote something
like:

> Device Naming:
> Why aren't all ttys tty0 - tty999 ?
> Why aren't all disks disk0 - disk999 ?
> Why aren't all network interfaces ether0 - ether999 ?
> Why aren't all framebuffer fb0 - fb999 ?
> Why aren't all tape devices mt0 - mt999?

    Assuming this is rhetorical here :-)

> Does the user care? Should the user care? At Sun we decided, "Nope, the
> user shouldn't care" and notice how all the disk devices in Solaris are
> /dev/dsk/c0t0s0 (that is "controller 0", "target 0", "slice 0") nobody
> cares if the disk is fiber channel, scsi, smd, etc. Its a disk. And it has
> a /dev/rdsk flavor as well.

    Why not merge the two schemes together? sc0t0s0 (SCSI Controller 0,
Target 0 (possibly Target@Lun for wide devices; 0:0]), slice 0? That limits
us to 26 different controller types, but that shouldn't be a problem, if it
is, add a third letter so it would be sdc*. (SCSI disk controller?) I
personally think c0t0s0 is going to add way too much indirection.

   I have to agree with Chuck on this, I'd much rather be able to tell fstab
*what* Controller:ID:partition my file system is on, rather than in what
order my drives happen to be connected on a certain bus protocol. The
current handling of it, in SCSIpi makes ones head spin. IMHO, the solution
to this would be to add an XXc*t*s* would be simplest for everything. If one
wants to add a logical indirection to device naming, it wouldn't be terribly
hard to set up later. mount /dev/sc0t0s0 isn't so hard to swallow, at the
expense of things making sense.

    How about cc'ing this discussion to tech-kern or current-users? I'm sure
device naming has been battled out before. Surely the veterans of said blood
bath could provide a little insight. While we're there, we can stir up a
raucous on why they still use Xd0d as the whole disk instead of Xd0c

> To that end I strive _not_ to duplicate code or effort and re-use code
> whereever possible. That buys you two things: First the kernel is smaller
> and second, it is generally more reliable since code already working is
> worth much more than elegant code conceived.

    Which leaves us right back at the existing catch-22. Make coding more
efficient, or make it somewhat organized and PI? I would certainly take PI.
We can't keep everyone happy. Concessions have to be made, deal. A working
driver beats no driver though, we can all agree on that I'm sure.

<OT> don't forget that the mipsel-pmax folk could use DSSI on the Qbus
machines </OT>

<snip>
> I find it interesting that one can argue both "follow DEC" with Ultrix and
> "ignore DEC" with VMS. If it were up to me the device name would be 'di*'
> and exactly match the name the prom shows. Sure would clear up some folks
> confusion.

    Well we need some level of indirection here I think, that would be going
from one extreme to the other (purely logical to purely physical naming). It
couldn't be as bad as MkLinux, where there are four(!) different ways you
refer to the same device at different points of boot. (MacOS, First stage
Booter, Second Stage booter, kernel; all different)

-- 

Murphy was an optimist.