As some of you are aware, there is a significant problem with the way
Torek's autoconfig works.  Essentially, the problem is that `probe'
routines (as opposed to `match' routines, which the SPARC code uses)
often figure out complicated state, and you generally don't want to
duplicate all of the work in the attach routine.

Now the problem here is where to store the information.  You could
create some special-purpose structure or just have one softc allocated
statically.  This is ugly.  You could do something I've done, which is
malloc() a softc in the probe routine, use it, and then copy the data
into the config-allocated one later.  This is fugly.  Basically, there
is no good solution without changing the autoconfig interface.

The essential problem is that the high-level config code needs to know
how to deal with `probe' routines--namely, by allocating the softc and
passing it to the `probe' routine, rather than deferring the allocation
until it's time to call the attach routine.

There are a couple of ways that come to mind to implement this:

1) Make everything use `probe' routines.  This is consistent, but the
overhead of malloc()ing and free()ing softc's is not necessary in a lot
of circumstances.  It's not terrible, but it's also not necessarily
what you want to do.

2) Implement both.  As an example, there could be a new field in the
cfdriver structure which selects which to use.  This allows for the
performance benefit of a `match' routine where applicable, and the
generality of a `probe' routine at the same time.  It's also source
compatible with existing code, which may be a consideration at this
point.

I plan to do something about this by Monday, and 2) seems like a
pretty reasonable plan.


------------------------------------------------------------------------------