Subject: Re: Proposed change to a whole load of drivers...
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Brett Lymn <blymn@awadi.com.au>
List: tech-kern
Date: 09/10/1996 18:03:08
According to Jonathan Stone:
>
>I don't understand what data you want, here. The device-attach
>arguments are probably long gone by the time you call this new
>method.

The drivers I had a look at did store the information in softc I
wanted OR the information was able to be found indirectly.

>The device softc isn't particulalry meaningful outside the device,
>though perhaps the "struct device" base class [sic] is.  Is the struct
>device what you want, or not? 

The struct device base class has some of the information I want.  The
name of the device and the type but the other details are hidden in
the driver softc.  Which, in itself, is not bad since nothing else
should be diddling with that information.  It just makes it hard to
directly determine how the machine is configured.

>(and what about
>not-completely-new-config drivers that don't hav a struct device as
>the first member of the soft? Is the hp300 completeley new-config
>yet?)
>

I have a reasonably recent current and there was no indication that I
could see in subr_autoconf.c that any drivers did not have the struct
device as the first member of softc.  I could have missed something
here.

>
>Actually, I think it's a really interesting idea. I'd proposed
>a scheme for inserting LKMs for "well-behaved, direct busses", which
>involved the bus-level driver using an extent map to run autoconfig
>only for unconfigured slots.
>

For some unconfigured devices it would make sense to run the
probe/attach code.  It could get interesting for some types of devices
where the probe code could interact with already configured devices.

For a configured device it would be fatal from what I understand.

>
>In contrast exporting configuration info for all supported devices
>out to user-space headers in /usr/include/machine definitely *isn't*.
>

Yeah - that one is dead, it was really ugly anyway.

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
  "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.