I have noted that in -current, NetBSD is trying to move toward a more
uniform and rational style for probing and attaching device drivers, and I
think this is all well and good.  I note, however, that, in the new regime
(without __BROKEN_INDIRECT_CONFIG, which I take to be an interim hack), the
match routine for the device has no access to a softc structure.  While I
can understand this and feel that it is largely a good thing, it makes
the probe process more difficult on busses on which probing is not necessarily
straightforward (such as ISA).  A lot of ISA drivers will construct, at least
partially, a softc structure and then proceed to twiddle the hardware some
and see if it responds as expected.  Under the new regime, how is it
anticipated that ISA match functions will operate?  Perhaps this hasn't been
fully explored yet, as I do note that many of the ISA drivers still do things
the old way and that i386/include/types.h has #define __BROKEN_INDIRECT_CONFIG.
Indeed, the only architecture with any ISA support that doesn't define
__BROKEN_INDIRECT_CONFIG is the alpha, and its ISA support is currently very
minimal.  Would it be proper for the probe routine to allocate some static
state information and then for the attach routine to use that information
if necessary?  What about drivers that support multiple instances?  Is it
even currently possible for an ISA driver (either with the old or new style
match function) to support the use of the * syntax in the config file or
is explicit mention of each device always needed for all ISA devices?  In the
event that such a driver does support multiple instances, will the match
routine be called repeatedly before the attach routine is called for the
first time?  If it is, then it would seem improper for the match routine
to use any static state which would be reused by the attach routine, and, yet,
in the new style, I see no way to have the match routine dynamically allocate
per-instance state.  I'm probably just missing something here.
-ben