Subject: Re: Proposed change to a whole load of drivers...
To: Brett Lymn <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/09/1996 23:53:28
Brett Lymn (email@example.com) 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
>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*.