> I can see three possible solutions to this:
> 
> 1) Do nothing and stipulate that kernel config files always should have
>    explicit unit-number declarations before wild-carded ones.  I don't
>    find this very appealing.

or, modify config so that it ouputs non-wildcard declarations before
wildcard declarations.  This seems to follow the spirit of what was
meant by the config files which do this.


> 2) Have config_search() make an effort to give priority to explicit
>    unit declarations over wild-carded ones.

This seems losing, but perhaps it makes sense to do something like:
	if the existing 'winner' has the same match value as the
	just-checked cfdata's match function, and the existing
	'winner' is a wildcarded entry, and the just checked cfdata
	is not, then make the just-checked entry the winner.

Unless i'm mistaken, however, this would have the same resulting
semantics as the modification I suggested above, but doing it this way
would have run-time, rather than config-time cost.  (Of course, the
cost wouldn't be much, and the cost doesn't really matter much since
it'd be done at autocnfig-time...)


> 3) Leave it to subsystem's match function to decide upon returned
>    priorities based on locators passed to it.
>    E.g., in the example, scsibussubmatch() could return a higher priority
>    value whenever one of its locators (target and lun) are present.
>    Since there are two locators, it should also implement a policy that
>    handles relative priorities, in case someone writes:
> 
> 	sd0	at scsibus? target 3 lun ?
> 	sd1	at scsibus? target ? lun 4
> 
>    for example.

I'd say that this is a good idea in general (and i've used it where I
thought it was appropriate), but shouldn't be necessary (and still
doesn't solve the problem when people say sd0 sd1 and sd* with _no_
interesting locators, for whatever reason).  I think fixing the
problem in config is a good idea too.



cgd