> Yes. Every PCI device has an identifying structure, and the structure is
> growing at an alarming rate. For instance, there is substructure for the
> base address register. Each base address register exists as a 32 bit
> register on the card, and most drivers only care about one of the first two
> registers (I/O vs. memory space). The structure now uses up to 32 bytes for
> each of the six possible (most are unused) registers.
>
> Now the argument you'll likely respond with is "who cares about a few
> hundred bytes". My point is that it has grown by 4X or 8X and added much
> complexity with no benefit for the vast majority of uses.
I agree the growth of struct pci_dev during the 2.3 development cycle
is alarming (I was proposing to allocate the resources dynamically,
but Linus was against), but I don't believe it has added any significant
complexity -- actually, the resource manager has become simpler and cleaner.
Although the drivers now have to know about the structure, they don't need
to do any bit masking on the base registers nor any other tricks to get
the base address of the device. The handling of resources inside the PCI
code is more complex, but it's also more powerful -- now the kernel knows
about all address space regions assigned to devices, so it can assign
addresses itself when it notices anything wrong (usually due to broken
BIOS) and it doesn't have to guess what address is free and what isn't.
> Uhmmm... No.
> We've been doing hot-pluggable PCI devices with CardBus for years.
Yes, you did, but without complete information about resources in the
system, so the address assignment policy was pretty heuristic.
> I think the problem is being approached in reverse. The issue is "given
> this 32 (rarely, 64) bit address register, how do we map it to virtual
> memory". This has very little to do with the device. The minimal
> additional piece of information is the bus it's on. So we should have a
> function like ioremap() that takes a integer that identifies the bus. For
> most systems the bus number will be a direct mapping of pci_bus, and the
> call will be just a wrapper for ioremap().
>
> The rare systems that are more complex e.g. with multiple peer PCI bus
> trees, can handle the complexity with a look-up table instead of treating it
> as just pci_bus.
The machines with multiple bus trees are not rare at all and their number
is still increasing. Normal drivers should not take care of bus topology
-- all they need to know is how to find the devices they handle and how
to access their configuration space, I/O, memory and interrupts.
Both `struct pci_dev' and your arrays indexed by bus number are abstractions.
The pci_dev one is a bit more abstract, but it's IMNSHO easier to handle
and it doesn't give a false image of a single bus tree where there is none.
> Particularly bad are abstraction layers where you need to both know the
> details of the underlying implementation and learn the new abstraction
> language. It's pretty clear that is the case here.
>
> A device driver write must know the details of the device, including PCI
> configuration space. This isn't a software structure that can be changed
> with a few editor commands. The basic PCI/CardBus configuration space
> registers and their semantics will be around forever.
The configuration registers will be around forever, but several aspects
of their semantics change. Of course, the base address registers still
contain base addresses from the bus point of view, but what do they really
mean to the host processor isn't an eternal truth. Once you start assuming
there can exist a machine with 64-bit address space and four 32-bit
PCI buses mapped there, your view of the world is going to change.
I don't want device driver authors to have to take care of all the
complexity and rapid changes of the today's world, so I've given them
a simple abstraction which contains everything vast majority of drivers
needs in a pre-cooked form (bus addresses translated to physical ones,
translated IRQ's, a handle for accessing configuration space etc.).
Of course, any driver wishing to touch the hardware registers directly
can bypass the abstractions and do what it wants.
> There is no point in pretending that an abstraction layer will let device
> drivers be bus independent, e.g. SBus vs. PCI, either. A very few might be,
> just as there are ISA devices hacked onto PCI cards.
I've never pretended we can handle all different bus types by the same
code -- it's clearly impossible. :-)
> But a PCI device driver usually need to set FIFO thresholds with knowledge of
> PCI bus characteristics
What characteristics do you have in mind?
> and recover from events like data parity errors by writing
> the PCI_COMMAND register in configuration space.
It still can. It's one of the primary reasons our PCI configuration access
functions are IRQ-safe.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "DOS never says "EXCELLENT command or filename"..."- 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/