[lkml]   [1999]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] pci probing
    On Sat, 11 Sep 1999, Martin Mares wrote:
    > Actually, I think there should exist two different versions -- one
    > for 2.3 which would make use of all the new PCI/resource stuff and a
    > backward-compatible one for 2.0--2.2. It would be better than one code
    > with zillions of #ifdef's and routines for doing things handled by the
    > generic code since ages.

    My interface seeks to minimize the #ifdef trees. I'm highly motivated to
    get rid of them, since they impact me more than anyone else.

    > > And a comment from pci-netif.c:
    > > > /* The PCI code in 2.2 is harder to use, and the extra complexity serves
    > > > no real purpose. The resource code in 2.3 is far worse. It is a complex
    > > > abstraction layer with negative benefit. */
    > Donald, I appreciate your excellent driver work, but I think that in this
    > case, you're wrong.
    > The PCI code in 2.2 cannot be harder to use even if the only reason were
    > that it's backward-compatible with the one in 2.3 :-) Also, can you tell
    > me any concrete example where the new PCI interface is harder to use?

    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.

    > 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

    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.

    >and other fancy stuff. Besides the problems with maintaining
    >backward-compatible drivers, what are the negative benefits?

    The code growth is a negative.
    The complexity growth is a negative.
    The unneeded abstraction layer is a negative.

    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.

    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. But a PCI device
    driver usually need to set FIFO thresholds with knowledge of PCI bus
    characteristics and recover from events like data parity errors by writing
    the PCI_COMMAND register in configuration space.

    To bring this letter back to the original topic: My goal is to minimize the
    size of the kernel. Sometimes it seems that everyone else's goal is to throw
    new stuff in as quickly as possible, without considering if it's really
    required. Specific example (please generalize rather than flame minor
    details): the kernel distribution now has a new amd79c961a driver for an
    almost-obsolete ISA chip. But the lance.c driver has supported this chip,
    along with many other versions of the LANCE, for years. Step back another
    level, and count how many LANCE drivers there are. (I'll skip the flame
    about them dropping my name when copying the code.) Almost all of them are
    redundant code, added because it's initially easier to add code bloat than
    to rethink the problem. But over the long term the larger code will be far
    more difficult to maintain and extend.

    [[ BTW, I do know that there is an intangible difference here: Martin Mares
    will be around for years to support his code. Many other "contributers" are
    only around long enough to add their names to the CREDITS file. ]]

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

     \ /
      Last update: 2005-03-22 13:53    [W:0.035 / U:0.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site