There are 16 resource structures in a pci_dev now. This wasn't due to
Martin, though: much of the expansion is because pci_dev is now
supposed to handle the union of PCI and PnP device needs. And because
of (imho) wrong-headed things like putting human-readable device
descriptions in the pci_dev struct.
The new PCI code did make CardBus support somewhat more complicated.
The code needed for initializing a new PCI device has gotten larger.
I have mixed feelings about this: I do think the linux device model
needed work, however, I've also grown to appreciate the philosophy of
keeping kernel interfaces simple. The current CardBus code fills in
enough fields to make things work, but with the latest kernel, that
means I'm leaving the majority of fields uninitialized.
The old interfaces did not make CardBus and hot plug stuff especially
difficult. The resource management changes also didn't really make
things any easier. The new resource code does distinguish between
reserving resources, and associating them with a device driver, and
that is useful. I can't use it for PCMCIA, however, because the
kernel can only pre-enumerate PCI resources for now. CardBus works
just as well in 2.0.* kernels as in the latest 2.3.* kernels: the only
deficiency in 2.0.* is the reliance on possibly buggy PCI BIOS's to
access configuration space.
> > Maybe the resource code in 2.3 is designed sub-optimally, but I'm
> > sure we really need such a thing if we want to support hot-pluggable
> > devices
>
> Uhmmm... No. We've been doing hot-pluggable PCI devices with CardBus
> for years. A valid concern is hot-pluggable bus bridges, but that's
> not what drove this change.
I'd have to agree with this. There may be some things for which the
new PCI code is better, but hot plug support is not one of them.
-- Dave Hinds
-
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/