Re: More linker magic..

Linus Torvalds (torvalds@transmeta.com)
Wed, 4 Aug 1999 17:03:59 -0700 (PDT)


Ok,
I was hoping that Martin would end up doing this, but as I'm forcing
myself to honour the feature freeze too, I decided I might as well forge
right ahead on the PCI resoruce issue because it will be needed for proper
PCMCIA integration.

pre-patch-2.3.13-5 does the proper resource allocation for all PCI cards;
instead of having the drivers do the resource building, the PCI layer
builds up the resource information automatically, and at least for the set
of drivers I was concerned about on my machine there wasn't even any need
to adjust the old compatibility stuff, but that will almost certainly be
needed for other sets of drivers (ie extending the resource flags with a
"BUSY" bit to mark resources as being exclusively used by some driver).

There are probably a number of broken PCI drivers, but they tend to be
fairly straightforward to fix, and often the fix cleans things up. For
example, there used to be a

pci_device->base_address[6]

array, where "base_address" wasn't really the base_address, it was really
the value in the PCI configuration space that is a mixture of base address
and flags. With the new scheme, there is

pci_device->resource[6]

where each resource has all the normal "start"/"end"/"flags" things, and
the fields actually do exactly what they say (so "flags" has the flags for
that region: IO vs Mem, 64-bit addressing etc, and "start" really is the
base address).

It also means that /proc/ioport and /proc/iomem actually show the full
population.

Broken non-updated drivers simply won't compile, but the fixes tend to be
rather straightforward. The less straightforward part is if some driver
tries to change the start offsets etc, which implies that he really has to
unregister the resource and re-register somewhere else. I don't know if
anybody actually does that, although I do know that there are drivers that
play some silly games with their resource list.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/