[lkml]   [1998]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.1.93..

Sorry for not replying for such a long time, but I was several miles
from nearest Internet connection during whole weekend.

> OK, I can see why you wouldn't want to take the BIOS order, then. But
> why not have the default be the reverse of what it is now, to be
> compatibile with 2.0.X? What order does 2.0.X use? Simply the reverse
> of 2.1.94+your patch?

In the old PCI code, Linux used the order returned by PCI BIOS functions
which is not specified by the PCI BIOS specs.

I didn't want Linux to depend on any ill-defined BIOS behaviour and use
direct hardware access to PCI config space whereever possible (there are only
two known ways how to access the config space and Linux knows both of them,
so it makes little sense to use a complex code for calling the BIOS when one
can simply touch the hardware) and I especially wanted to keep the card ordering
the same for both BIOS and direct access modes, so that if you re-configure
the kernel, everything still works as it did before.

> I do not find pci=reverse to be an acceptable solution.

Well, it's probably the only solution if you want the kernel to use a
well-defined ordering of devices. Nobody even says that the BIOS should return
the same order for every boot.

> 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.

| Why not keep the BIOS order. Its the order in every other OS you boot on the
| same machine, its an order available to you and it means little things like
| Lilo and the OS agree which bios disk is which linux disk.

The main reason is that depending on things you know only a little about
is usually unwise.

| The change is utterly pointless. We should use BIOS order on a PC at least.
| BIOS order is the existing, normal and defacto ordering for such systems. Like
| it or not.

> If pcibios_find_device were so buggy, I expect I'd have received many
> complaints by now.

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

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?

Have a nice fortnight
Martin `MJ' Mares <>
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"A jury consists of 12 persons chosen to decide who has the better lawyer."

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

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