Um, remember that the design allows (but does not require) multiple
matches in the probe routine.  This means that you cannot just go
and replace `?' with `3' in a probe routine, as a later probe might
want to replace it with `4'.  That is, to give a hypothetical example
of a call trace:

	fooattach() {
		...
		pri = xxprobe(...);	/* returns 1, a match */
		pri = yyprobe(...);	/* returns 0, no match */
		pri = zzprobe(...);	/* returns 2, overrides xxprobe */
		pri = wwprobe(...);	/* returns 1, not taken */
		/* done probing */

		/* now that we have decided on zz: */
		zzatach(...);
		...
	}

In this situation, it is essential that no probe routine modify any
data.  Here zzattach must in essense repeat the work zzprobe did, if
any, in order to decide on values for wildcarded configurations.

Now, you can elect not to do things this way.  In fact, you can
have your own routine called for all configured devices; this is
necessary on things like the VAX UNIBUS, where the uba driver must
condition the UNIBUS before and after each probe.  That is,
subr_autoconf.c does not call any of the device probe routines
directly, but rather through an intermediary.  This intermediary
is free to use a different call interface, and a different sort of
probe, through the bus-specific driver pointer:

	struct ubadriver *ud;
	ud = cf->cf_driver->cd_aux;

	... initial uba setup ...
	ret = ud->ud_probe(...);
	... clear uba faults ...
	if (ret != 0)
		config_found(...);

This can use the auxiliary data areas to store information
discovered during the probe, as the device attach routine will
be called next (via config_found).  Not elegant, but serviceable.

(Everyone got that? :-) )

Chris

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