> Could someone explain to me, what is the advantage for this order.
> To me it seems a little bit stupid to change the device number when
> another device is add to the scsi-bus.

I think the big reason is that tapes, CD's, scanners, and hard disks
each have their own type (st, cd, ss, and sd), and that we support
multiple scsi busses (well mac68k doesn't yet, but NetBSD does, and
port-mac68k will as we get better drivers). If we did not dynamically
assign the addresses, we'd get into an inordinate number of device
names. Say you have a machine w/ internal and external SCSI busses,
and two drives on the internal bus. Or say a cdrom and a hard disk.
On the external bus, you add a hard disk. With the assignment
scheme, you have cd0 (internal), sd0 (internal), and sd1 (external).
With fixed addresses, the lowest number available for the external
would be sd8X. Plus you'd really need ALL of the sd devices to be
made in /dev. We're talking over 100 files to fully support the
possablilities (14 devices*8 partitions).

So you have a choice. You can either live with moving ID #'s,
or you can play with lots of files in /dev. At first, I
really didn't like NetBSD's scheme, but I see how it will scale
better. And for things like CD-ROM's, scanners, and tape drives,
where you probably only have one, you only need one set of
device files, not one for each place you might attach the device.

One additional note. You (and I, actually) are running GENERIC kernels.
These are designed to be good for a distribution. As you get settled
with NetBSD, the idea is you should build your own kernels. It
could just be you have the standard distribution source, and compile
a kernel (no fancy stuff, not on the bleading edge). But you certainly
can wire down your SCSI addresses. You can make a kernel which will
always put sd0, sd1, and sd2 where you want them, and then add
a config option to catch any new devices. Thus the #'s won't move
around on you.

Take care,

Bill