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