According to Chris G Demetriou:
>
>Quite frankly, doing it that way is _stupid_, for several reasons:
>
>	(1) why do all of the headers end up in /usr/include/machine?
>	    Many of them have nothing to do with machine-dependent
>	    code.
>

Just a suggestion, I was open to a better place.

>	(2) your talking abuout exporting dozens of new header files
>	    to user-land.  That, in itself, is objectionable.
>

Yes, I was not enamoured with the concept but with the approach I have
taken it seemed to be the only way to do it given the current location
of the information I wanted to extract.

>	(3) softc contents are intended solely for the private use
>	    of drivers.  Your approach would encourage others 
>	    (your program included) to muck around with the internals
>	    of others' softcs, which violates a hell of a lot of
>	    abstraction barriers and is generally "Wrong."
>

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.

>	(4) Your approach does not and cannot scale.  Add a new
>	    driver, you need to add new code to your program.  That's
>	    broken. 
>

see (2)  :-)

>	(5) You already have a way to find out how a device was
>	    configured (not necessarily how it actually looks, but
>	    how it was configured), in the devices' cfdata.
>	

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)....
    
>
>If you're trying to show exactly what's in the machine and how it's
>configured, use dmesg or /var/log/messages, or whatever.  It's
>got as much accurate information as it can have, and it's already
>readable.
>

Ahh but it does rely on correctly parsing the textual output to find
the correct bits of data which can be a bit dicey in places methinks.
I have not had a really close look but (4) may apply, at least
partially, in this case as there is no guarantee that all the drivers
will report their data in the same way.  I was keen on doing it this
way when I started but I _thought_ that fishing the information
directly from the kernel would be a more reliable information source.
I did not know that the stuff was that well hidden.  I babbled
something about using the approach of fishing the kernel for
information on the mailing list a while ago, nobody said anything
about it being a dumb idea at the time :-(

Nutting out how the auto_configuration is done has been quite
educational and I don't care about dumping the approach but I do see
problems with getting the information from dmesg.

>If you're trying to generate a new config file, then you already have
>ways to do what you want without resorting to this (in my opinion,
>very ill-considered) hack; see (5) above.
>

Ultimately, yes that is what I would like to do - doing a prtconf
style command is a starting point because the information that is
needed by both commands is the same, just what you do with it later
that is different.

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