> >From: Ben Tober <tober@bbnplanet.com>
> >
> >	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.
> 
> It shouldn't need a softc; everything it needs should be stored in the
> isa_attach_args structure.  All the match routine has to do is
> determine if hardware it supports is present at the location given by
> the isa_attach_args structure.  It should do nothing else.

Close, but not entirely true:

	(1) it should make sure that the various spaces that it would
	    use can be mapped (and then unmap them), and

	(2) (for ISA and other indirect-config busses) it should
	    figure out 'good' values for any attach_args elements
	    which have been wildcarded, and fill them in in the
	    attach args so that the bus knows what was picked.


> >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?
> 
> NO.

"A-MEN!"


> >  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?
> 
> The only exception would be a device like if_ep, which supports a
> small number of hardwired port locations.  The match routine can
> examine each one (*); if it finds the hardware, it fills in the
> isa_attach_args structure and returns a 1.
> 
> (*) each one that hasn't already been found; avoiding multiple hits at
> the same location is one reason why we need <sys/extent.h>.

More or less right:

"has already been found" is determined by being able to map the
relevant port spaces.  If you can't do it, then there's already a
device there.  Once you do that, you only need to look until you find
one that's good to go, or until you've exhausted the possibilities
that you'd normally try.


However, right now (even ignoring the fact that the i386 panic's in
the ISA code if it sees an FSTATE_STAR device 8-), there're still
limitations about when '*'d devices on indirect-config busses will
actually match/attach multiple units.

Because of the way config_search() works (invoking the match function
once for each cf with the specified parent), it doesn't (can't) handle
match/attach of multiple units for a *'d device on an indirect config
bus directly.  (I say can't, because changing it to do so would break
other functions that use it.)

It would seem that the 'right' fix is to rework isasearch() to
resemble something like:

	int tryagain;

	do {
		... set up isa_attach_args for child ...
		tryagain = 0;
		if (... child matches ...) {
			... attach child ...
			tryagain = (child cf_fstat == FSTATE_STAR);
		}
	} while (attached);

Other indirect config busses could probably benefit from similar code.
(i've not made that change to the isa bus code, and don't intend to
for a while.  "eventually..."  The problem is, because of the
__BROKEN_INDIRECT_CONFIG softc allocation which the isa bus/driver
code currently relies on, such a scheme cannot work until
__BROKEN_INDIRECT_CONFIG goes away.)



chris