Brett Lymn (blymn@awadi.com.au) writes:

>See (2) .... Alternatively, what about a method that would report the
>devices configuration?  Something that is part of the driver that
>reports the configuration to the caller, something similar to the
>print function the autoconf calls excepting that it returns the data
>to the caller.  That would keep the abstraction barrier (a good thing)
>but allow the appropriate data to be retrieved.

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 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? (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?)


>Yes I know - like I said, I wanted more than where the device was
>attached and who configured it.  Calling the attach or probe functions
>on a running device is not what I would call a very good idea (read
>that as really stupid)....

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.

An alterative is to mandate that _all_ drivers must keep track of the
autoconfig address (the csr, in 4.3vax terms) of all devices that
they've configured, and return a new and distinct return value from
the match routine for any such device.  Then, just perhaps,
re-invoking autoconfiguration might do exactly what  Brett wants.

this is, of course,  complete speculation, may not work, and there
may well be over-riding or compelling reasons not to do it.
But there's a chance it could be bashed into something acceptable.
In contrast exporting configuration info for all supported devices
out to user-space headers in /usr/include/machine definitely *isn't*.