lkml.org 
[lkml]   [1998]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.155 / U:0.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site