> Take the NCR driver, for instance:
> 
>    ncr0 targ 0 lun 0: <QUANTUM, XP34301, 1051> SCSI2 0/direct fixed
>    sd0 at scsibus0sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8.
>    : 4106MB, 4076 cyl, 20 head, 103 sec, 512 bytes/sec

That's really a bug in the NCR driver, rather than anything else.  (It
doesn't print negotiation messages in any 'sane', organized way.)


> Incidently, grabbing the <QUANTUM, XP34301, 1051> in a standard way
> would be neat, too [ ... ]

right now, the SCSI code attaches things like (minus ncr negotiation
printf):

ncr0: restart (scsi reset).
scsibus0 at ncr0
ncr0 targ 0 lun 0: <DEC, RZ26L    (C) DEC, 442D> SCSI2 0/direct fixed
sd0 at scsibus0: 1001MB, 3117 cyl, 8 head, 82 sec, 512 bytes/sec

It think it would be done much better as:

scsibus0 at ncr0
sd0 at scsibus0 targ 0 lun 0: <DEC, RZ26L    (C) DEC, 442D> SCSI2 0/direct fixed 
sd0: 1001MB, 3117 cyl, 8 head, 82 sec, 512 bytes/sec

(and, for unsupported/unconfigured devices:
<DEC, RZ26L    (C) DEC, 442D> SCSI2 0/direct fixed at scsibus0 targ 0 lun 0 not supported
or something similar)


There's some redundancy in the way it's done now, but the fact that
"ncr0 targ 0 lun 0" is sd0 is never directly established (as it is
with my version).  Additionally, I don't really think that the current
way is in line with the way the configuration code is meant to be
used...


> Also, it would be nice if disk drives and network interfaces gave you
> enough information about themselves that you didn't need to hard code
> what the device names were -- among other things, that could help in
> trying to make the install stuff machine independent and more
> maintainable.

it's very easy to have a machine-specific list of devices of "given
types" -- haven't we gone through this before, already?


> > This is similar to the approach Paul and I took with the hp300/sparc (and 
> > sun3, too) install.sh.  Eventually, most (all?) ports might be able to 
> > use this script after .'ing in a machine-dependent module that defines 
> > certain functions.
> 
> I'd rather see things standardize sufficiently that you don't need
> much in the way of machine dependant stuff at all...

I think that's unreasonable.  either:
	(1) there are machine-specific lists, or code to handle weird
	    devices, 
	(2) there are no machine-specific lists and every device
	    type is known to the machine-independent code and/or
	    'standardized'

(2) has some disadvantages:
	(a) driver name collisions might cause problems,

	(b) how are devices of a given type recognized?  what
	    if there are two different types of drivers that
	    want 'similar' autoconfig output, but shouldn't
	    be treated identically?  certainly, it's unacceptable
	    to have "le0: ETHERNET DEVICE" spit out at boot time...
	    8-) 


chris