Messages in this thread | | | Date | Tue, 14 Apr 1998 21:49:32 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: 2.1.93.. |
| |
On Tue, 14 Apr 1998, Leonard N. Zubkoff wrote:
> Date: Tue, 14 Apr 1998 15:24:45 +0200 > From: Martin Mares <mj@atrey.karlin.mff.cuni.cz> > > 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.
That's poor setup feature IMHO. You should suggest Mylex guys to offer a boot order setup for their products. This will avoid Linux to provide historical silly things. I replace my motherboard and processor at least twice more often that my controllers and peripherals. If boot order relied on PCI BIOS implementation or on the actual PCI slot order, I would be in the shit every 18 months.
> If all other drivers really do want the old order, then changing it was the > wrong idea in the first place.
There is things that requires to guess the actual boot order. But this is just guessing and this may fail. It is a good thing IMO to get rid of such guessing in order to be encouraged to make things ok.
> 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?
Agreed for 2.2, since things are not clean enough to get rid of pcibios_find_device() immediately. But I propose not to rely anymore on the PCI BIOS for 2.3.
> 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?
Such a config option make things too complex IMO. The reverse order is not more silly than the opposite, it is only different. Given the problems encountered, I think the only reasonnable decision is to reverse this change.
> 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.
When you switch to a different distributions, you can have also other sorts of problems since they are not identical. Boot order problems are just some of them.
> 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.
Are you sure, this information will always be enough to guess all what you need. It may exist lots of subtle configurable options in the boards set-ups that can confuse any heuristic based on BIOS stuff guessing.
Gerard.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |