Subject: Re: Proposed change to a whole load of drivers...
To: Brett Lymn <blymn@awadi.com.au>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
List: tech-kern
Date: 09/09/1996 09:36:51
> I want to be able to print out the memory i/o address, dma channel (if
> any) and interrupt.  This means I need to get the softc structure for
> each of the drivers.  The problem is that, currently, they are
> embedded into the driver code itself which means I either need to
> parallel the structure in my own code (dangerous and not very nice) or
> put the softc structure into a header I can include.  If there are no
> objections, what I would like to do is create a header file for each
> driver which contains the softc struct and have then installed into
> /usr/include/machine.

In a word, "NO."

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.

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

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

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

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

> Any comments/screams/alternatives?

"See above."


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.

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.


chris