Subject: Re: DSSI update
To: Todd Vierling <tv@wasabisystems.com>
From: Brian Hechinger <wonko@entropy.tmok.com>
List: port-vax
Date: 02/07/2001 10:44:54
Todd Vierling drunkenly mumbled...
> 
> Note that we do provide a hardwired kernel (GENERIC_SCSI3) for just this
> purpose on sparc (hardwiring IDs 0-3 to /dev/sd[3-0], respectively).

i was unaware of that, but not a large problem, since at least i could overcome
the problem i didn't look very hard for an alternative like the GENERIC_SCSI3
kernel.

> into the *millions*.  Now, if we had controller-based device nodes (a la
> SVR4/Solaris, /dev/dsk/cNtNdNsN), that may be easier to your way of
> thinking, but even Solaris does our kind of dynamic mapping when it comes to
> the SunOS compatibility /dev/sdN* nodes.

Solaris also does dynamic mapping of actual devices.  i want to replace my le1
with hme0 but that turns le2 into le1 and now my IPFILTER config will be wrong.

as annoying as static could potentially be, it also has some large benefits.
maybe the two ways should be merged?  there would be a "real" device tree which
would be really super ugly. and an "alias" device tree that can look however
you want it to.  although, the example of using SBus slot ID only works with
slot based systems and would be 100% broken on any of the busses based on ISA
for example (PCI being pretty popular these days)

anyway, the point is, i could use the "real" tree for devices that shouldn't
ever move (like disks and network controllers) and use the "alias" tree for
stuff like say /dev/fb0 since i could care less if that changes since it's a
non-operational impact.  so i gotta telnet in and fix it, big deal, but if my
network devices got munged up, i can't telnet in, ok, so i serial console. but
what if my machine won't even boot since it's looking in the wrong place?  now,
instead of hop on, fix, hop off, i must endure a large amount of screwing
around to get myself back to an operational state.  ok, not such a huge deal,
but that's for my small setups.  what about a maching with 100+ disks? do *YOU*
want to try and deal with that? good, cause neither do i.

> However, once your system is set up, you can hardwire your kernel by
> reconfiguring it, and once done, your existing disks won't budge if new ones
> are added.

maybe doing a kernel config with the exact hardware set is the "correct"
answer.  but what if i have 100 machines and they are all configured 
differently?  well now i either have to build 100 kernels with the correct
device mappings in the config file, OR, it could just do the Right Thing(TM)
out of the box, no modifications nessesary.

> So what did I miss?

nothing as far as i can see.

in summary: i'm not a very good programmer, in fact, i'm a LOUSY programmer.  
but in my not so humble opinion, i'm one hell of an admin.  so keep in mind 
that everything i say comes from a purely admin point of view and is not at 
all influenced by the programming philosophy you guys believe in.  like i said 
before, Sun was right.  i don't care how it works, as long as it works, 
reliably and consistantly.

is Solaris perfect? of course not.  but there are some points of it that make
it far easier to admin than BSD.  there are also point of BSD that make it
easier to admin than Solaris.  what we should be trying to achieve (i would
hope) is not only an OS that is technically superior to everything else, but
also one that is easier to maintain.  floating device number does not make for
an easy system of maintaining.

-brian