Subject: kernel config declaration order
To: None <tech-kern@NetBSD.ORG>
From: Paul Kranenburg <pk@cs.few.eur.nl>
List: tech-kern
Date: 03/30/1997 14:15:03
For instance, the sparc port currently has a kernel configuration file
called GENERIC_SCSI3 which consists of an "include" of GENERIC
followed by some lines pinning down unit numbers to specific SCSI targets.
This doesn't work, because of the effective order of wild-carded versus
explicit unit assignment lines, which is:

	sd*     at scsibus? target ? lun ?              # SCSI disks
	sd0     at scsibus? target 3 lun ?              # first SCSI disk

These appear in the the generated cfdata[] array in the same order and
config_search() processes those lines in that order when asked to match
a SCSI device (at target 3) found by the SCSI system.

Assuming that there's just a single disk at target 3 in a system, the
above config lines cause this disk to be attached as `sd1' while `sd0'
does not get configured at all.

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.

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

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'm inclined to think that 2) is actually a reasonable thing to do. It's
easy to implement, but I'm not sure this won't break anything that relies
on the current semantics.

Comments?

-pk