This is still Berkeley UNIX here. since the beginning, device names have
followed the names of the relevant drivers in the kernel. something
named foo5 was probably the sixth (starting at 0) device configured by
the driver foo. That's the important thing there- Berkeley UNIX already
has a clear convention for naming devices based on what drivers configured
them at boot time. The solaris-style naming i personally find to be
absolutely awful, but aside from that, has no place in Berkeley UNIX. 
If this were NetSysV or NetSolaris, then maybe that'd be appropriate. 
this is NetBSD. 
nobody says names have to be two letters. true, just about every disk
device is named with two letters, but nobody said it has to be. 

isildur


On Thu, 8 Feb 2001, Chris Tribo wrote:
> 
>     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.