Subject: Re: Impending subr_autoconf.c changes
To: None <>
From: Chris Torek <torek@BSDI.COM>
List: tech-kern
Date: 02/02/1994 16:07:04
[smart remark first :-) ]

>As it stands, subr_autoconf.c is highly geared toward (to use your
>term) `direct' configuration devices, and is a major kluge to use for
>`indirect' configuration.

That's 'cos indirect configuration itself is a kludge, to be used
only on braindead hardware. :-)

>Frankly, I think that is a highly bogus way to do it.  The fact is, I
>often *do* want to set up part of the softc inside the probe routine ...

As I said, this is not generally viable when multiple devices can
match.  One or more matches will be discarded, so any state saved
must by definition be temporary.  On the other hand, I suppose we
can observe that since matching is prioritized, at most two states
need be outstanding at any one time.  (`Two' because until any
given match function returns, we do not know whether its state is
more or less important than a previous state.)  Hence we might have
something like:

	bestpri = 0;
	bestmatch = NULL;
	beststate = NULL;
	for (cd \elem all possible matches) {
		pri = cd->cd_match(..., &state);
		if (pri <= bestpri) {
			if (state) {
				/* he thought he was it, but he is wrong */
				cd->cd_dispose(..., state);
		if (beststate != NULL) {
			/* someone else thought he was it, but no longer */
			bestmatch->cd_dispose(..., beststate);
		bestpri = pri;
		bestmatch = cd;
		beststate = state;

(this is just an outline; the hard work is in deciding who allocates
the state, and when and where, and depending on that, cd_dispose may
not be needed).

>Coding the driver so the higher level routines don't need a softc
>would be a pain and make it larger and slower,

(depends ... sometimes, certainly; probably often in pc drivers.)

>and duplicating half the driver is just not a reasonable option.


>And using my own configuration routine is possible, but why bother to
>recreate this code in every place that needs it rather than in the
>high-level config code itself?

I suspect you will find each indirect driver has some common code you
could move to this routine (but the code is different for each bus).