Sorry for not replying for such a long time, but I was several miles
from nearest Internet connection during whole weekend.
> I think the simplest solution would be to add a new call that allows one to
> iterate using the BIOS order where necessary, but then returns the
> PCI_Device struct rather than the individual bus/device/function numbers as
> previously.
The problem is that exactly the same problems arise with network cards, so
all drivers would end up using this call instead of using the kernel order,
which is just equivalent to reverting back to the old order.
I disagree. There is no fundamental reason that either ordering is more
"correct" for network cards. Here we have historical precedent to deal with,
but that's all. It is not completely outrageous to change the ordering if
sufficient warning is given.
With BusLogic SCSI and Mylex DAC960 boards that have their own BIOS there is a
more fundamental issue: the BIOS itself iterates using the PCI BIOS function in
order to determine the order of board recognition (and hence which device to
boot from), and this information *must* be available to the driver.
If all other drivers really do want the old order, then changing it was the
wrong idea in the first place.
pcibios_find_device is usually not broken, but the PCI BIOS itself is. I've
already seen BIOSes that crash when asked to do less common things (like
reading config data from a non-existing card). So I vote for not using the
BIOS whenever possible.
Hence my proposal: The kernel finds the devices directly using direct access
which avoids PCI BIOS problems, and the PCI BIOS pcibios_find_device function
is only used when requested by a driver, but the information from the direct
probe is returned. That is the minimum possible use of the PCI BIOS, is it
not?
I propose that we add a config-time option forcing the kernel to use PCI BIOS
ordering for its device list. IMHO we shouldn't do such things unless we're
explicitly asked to do them. OK?
If it becomes a configuration time option, this will leave me little option but
to print large warnings in the BusLogic and DAC960 drivers if the option is
enabled. If the option must be set a particular way for proper operation of
the BusLogic driver, that pretty much guarantees that all distributions will
ship with the option set that way.
Destroying the information I need for proper driver operation is simply not
acceptable, whether under a configuration option or not. I still believe the
proposal I made above is the best way we can resolve this.
Leonard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu