Jason Thorpe writes:
>  > BTW, I know it isn't directly related, but while pondering improving
>  > the automation of installs recently, I noticed how inconsistent kernel
>  > probe messages for various disks and network controllers were, which
>  > makes it hard to extract the information you need by awking
>  > /kern/msgbuf -- which is going to be the method of choice on the i386
>  > at least.
> 
> Well, for ports that use MI SCSI, finding the SCSI disk devices should be 
> easy:
> 
> md_get_diskdevs() {
> 	# return available disk devices
> 	grep "^sd.*bus.*:*cyl," /kern/msgbuf | awk '{print $1}' | sort -u
> }

Doesn't actually work with all devices.

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

A bunch of this stuff is really very non-standardized except for a
small bit of it.

Incidently, grabbing the <QUANTUM, XP34301, 1051> in a standard way
would be neat, too, because then install could present the user with a
list like:

   Install on which of the following?

   1) sd0: [QUANTUM, XP34301, 1051]   4106MB
   2) sd2: [BAMBLEWEENIE 6000]        9012MB

> md_get_ifdefs() {
> 	# return available network interfaces
> 	for _netifname in ed el eg ep ie le; do
> 		grep "^${netifname}.* " | awk '{print $1}' | sort -u
> 	done
> }

This is also insufficient. I'd like to be able to pull a bunch of
information out like hardware address and other stuff. Again, its all
hard when you don't really have standardization on the printout.

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.

> 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...

Perry