[ On Sat, October 3, 1998 at 15:18:14 (-0700), John Nemeth wrote: ]
> Subject: Re: Another changer, another changer problem
>
>      Really?  With just a quick glance at the machine can you tell me
> what "c2" is?  Nine times out of ten you won't be able to do that.  99
> per cent of the time I do system administration remotely, and
> therefore can't look at the physical hardware.  "c2t15d0" is just as
> arbitrary as "sd47", except that it is longer and very awkward to
> type.  Now explain to me why SysV scheme makes so much more sense.

Perhaps you're not thinking of *real* machines.  Certainly with PCs you
are likely to be correct, but with all *real* machines that I've ever
dealt with you can easily find "c2".  On most such systems you won't
even have to decode switch or jumper settings.  If I plug a second and
third host adapter into the sbus slots on my sparcstations I'll have
absolutley no trouble figuring out which is which.  All the world's not
a PC, luckily.  I feel almost as little compassion for PC users as I do
for users of Microsoft products.  They made their choice -- let'm burn!

Seriously though, maybe a pure cNtNdN scheme isn't good enough for
NetBSD.  Maybe it's better to stick to driver prefixes, but be more
explicit about it -- i.e. don't lump all SCSI controllers into sd and
st, and so on, but actually use espNtNlN and so on.

This little bit of "middle of the road" stuff the BSDs are currently
trying with SCSI is what's causing the problem.  Going totally generic
in device naming (and major number assignment), such as calling all NICs
/dev/nicN regardless of which driver they are may not be appropriate for
NetBSD as a whole, so the alternative is to back out of this SCSI
confusion and go back to being explicit about which card various disks
and LUNs are attachec to by using names such as /dev/esp0t0l0 and
/dev/ncr0t0l0 and /dev/ahc0t0l0, etc.  Surely you can tell the
difference between your NCR card and your Adaptec card, no?  If what
Jason says is right then it should still be easy enough to tell which is
the "first" NCR card, and which is the second one, etc. (unless you're
stuck with a stupid motherboard like some of the ASUS ones which seem to
interleave pci0 and pci1 slots in a seemingly random pattern).

>      One of the reason I run NetBSD is because it is BSD!  If NetBSD
> were to become yet another variant of SysV, I, and probably many
>  others, would be looking for another operating system to use.  I've
> administrated just about every major variant of SysV at one time or
> another, and I really don't like it.  It has major bloat and a lot of
> unnecessary complexity (especially in the areas of I/O and boot time
> configuration).  If you want SysV, then you know where to find it.

Ah, jeez, why is it that so many people get all confused about this
issue and take sides without ever really doing any real accounting of
what's what and where the pros and cons really are??????

I run NetBSD because it has reasonably high quality source code that
runs on many platforms, and *because* I have the source code for it.

There are many things about it that I don't like, and there are many
things about it that I would prefer to change, but unless/until I want
to cause another chasm in the BSD camps by creating yet another variant,
I'm going to try and encourage NetBSD to look slightly beyond the OS R&D
venue it currently harbours in and take some heed of the requirments of
real-world 

> Note, that this rant isn't just aimed at you, but rather everybody
> that is trying to turn NetBSD into SysV (*especially* Greg, who keeps
> restarting this idiotic discussion every few months).

Now this is total bullshit.  I've not discussed rationalization of
device naming since somewhere around, or even before, the NetBSD 1.2
days, and the only other issue I can think of that I keep badgering
people about is getting a *real* init with proper run level support.  If
you want to make these kinds of false acusations you should do so in
private.  If it were only me you might have a point, but I'm usually
only the seconder on such suggestions these days.

Even if I mention in passing that I once ran a bunch of SysV machines
people in the BSD camps will get all jumpy and introspective.  If
instead I actually come out and claim I prefer Research Unix BSDers get
all glassy eyed and most have no idea at all what I'm talking about.

How about we change the pathname separator in NetBSD so it looks more
like Multics?  That would *really* make me feel more at home!  Or how
about we throw out all the BSD crap and make it NetV7?

>      Tell me what "the 1st SCSI controller attached to this system"
> is.  In general, you can't.  Heck, you can't even depend on the OS not
> to re-arrange the controllers on you.  That blows your whole argument
> out of the water.  On the HP I have, c0 is a card sitting in an EISA
> (aka GSC) slot, and c1 is the "Built-in SCSI".  Does that make any
> sense?  Of course not.

I've no idea what HP hardware looks like never mind how it works.

However I must ask the obvious question:  what OS are you talking about
here?  HP-UX?  If so, what's the upgrade history of that machine?  I've
heard that HP-UX does stupid things to try and preserve ancient mappings
after new hardware is added.  Nobody I know has *ever* put HP-UX up on a
pedestal of good OS design, let alone me.

Bad examples from systems of bad design are meaningless -- of course
they're bad.

I never had these kinds of problems on my 3b2s.

> tagged onto the end of the list.  Why should I have to remember to use
> 'mount /dev/dsk/c1t2d0 /cdrom' (taken from an HP-UX system just now; I
> had to use ioscan to remind myself where the cdrom drive is) as
> opposed to simply 'mount /dev/cd0a /cdrom' in order to view a cdrom?

That begs the question:  Why didn't you just type "mount /cdrom"?????

Surely c1t2d0 is no more meaningful to a naive user than cd0a is.  The
proper place to encode these kinds of mappings is in a user-level
configuration file such as /etc/fstab.  And of course then there's the
advantage of suggestions such as David Maxwell's to think about here
too.

PLEASE forget about your partisan views and look at the merits of
changes.  I don't make these suggestions lightly -- they're based on
actual real-world requirements.

After all, SysV didn't get the way it was totally by accident.  Quite
often some of its features were indeed designed to solve real-world
problems.  Remember that BSD has never really had a history of catering
to real-world production uses (such as running major telco central
office switches and billing systems), whereas some commercial operating
systems, such as AT&T's System V Unix were directly under the gun to
cater specifically to real-world production users.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>