lkml.org 
[lkml]   [1999]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] pci probing
    On Sat, 11 Sep 1999, Jeff Garzik wrote:

    > Donald Becker wrote:
    > > There is very little that is network-specific about the code.
    > > It's certainly not "network centric".
    >
    > That was shorthand for
    > only-applicable-to-your-net-drivers-without-changes. Sorry. :) Or in
    > other words, using that code unchanged will cause problems in my
    > drivers. :)

    The pci-scan code doesn't need changes.
    The code that uses it will need to change. But that's a given, and it will
    make most PCI drivers noticeably smaller and better.

    If you mean that it only works with net drivers, you are wrong. I've used
    it with various types of drivers. You see only net drivers because they are
    pretty much the only driver type I public-ally support. I've written many
    drivers that I don't release, because writing the code is only a tiny
    fraction of the work. (c.f. the drop-and-run style of releasing code)

    > > Questions:
    > > Does your approach handle hot-swap PCI and CardBus with a single driver?
    > Maybe.

    The point is I thought my initial versions supported it, and only when I
    wrote the code to prove it did I realize what was missing.

    > > What about ACPI and Wake-on-*?
    > Check out the patch at the end of the message to which you replied.

    I mean a way to set Wake-On-LAN/Wake-On-Ring/Wake-On-USB when shutting the
    device down.

    The transparent ACPI wake-up is important because many chips are being
    updated to PCI v2.1 ACPI without changing the PCI IDs or programming
    interface. An older device driver will work once the device is changed to
    D0 state, but the OS shouldn't just turn everything to full power at boot.

    > > Does allow backwards- and forward-compatible drivers?
    > Nothing prevents the interface from being backported to older kernels
    > verbatim.

    Sure, you can "backport" the interface just by applying all the kernel
    patches to bring the kernel up to the latest version. That's not what I
    mean.

    One of my design criteria was that the backward compatibility must be
    obvious, small, and not require recompiling the older kernels. My approach
    drops into a 2.0.*-based distribution from several years ago using only
    a small additional pci-scan module. It's drops into the PCMCIA support
    (assuming it is recent enough for CardBus) with only a small cb_shim.o
    module, the new driver modules, and the text updates to the config.opts file.

    I know some of the other developers don't think that backwards compatibility
    is important. I think it's very important, and I'll tie to future work: if
    the semantics don't match well enough to be backward compatible we should be
    looking at the reason. We should understand what we did wrong so we are
    certain we are fixing the real problem.

    The scale of changes over time is also telling: a small change to an
    interface means that something is subtly wrong with the design.
    A significant change means that something is seriously wrong with design.
    Arbitrary or multiple changes means that something is wrong with the designer.

    > The central problem is that the pci-netif.c code is not a drop-in
    > replacement for existing PCI probe code.

    Nothing will be a drop-in replacement. Most of the current scan code is
    ad hoc. Where it's similar, it's because the code semi-cribbed from some
    other driver, usually not a clean one.

    > However, if changing your code to be more generic means lots of private
    > development and testing, it will be ages before anyone but you can stop
    > duplicating code in their drivers.

    Yes, it has taken ages -- it's a derivative of the code I've been using and
    refining for years.
    The current version has
    documentation
    support for every kernel version with PCI functions (later 1.1.*, 2.[123].*)
    an annotated example driver
    over a dozen real driver ports
    a working interface to CardBus

    The comment about "changing .. to be more generic" is spurious. The only
    thing network-specific is the current file name (pci-netif.[ch] when it
    should be renamed pci-scan.[ch]), and a special case for if-name
    vs. major/minor numbers in cb_shim.c due to some ugliness in the CardBus
    interface. I'm the author or co-author on all but two of the CardBus
    client drivers, so I'm pretty that aspect is pretty well covered.

    > > ??? The PCI_COMMAND stuff isn't a whim.
    > > It, like the latency correction and ACPI wake-up, is required for some systems.
    >
    > It's bad news for video cards at least in its current form, though.
    > Turning on I/O decoding blindly is just asking for a lockup, with
    > multiple VGA cards. But don't worry, as I stated in another e-mail in
    > this thread, PCI_COMMAND will definitely be used. I just need it more
    > flexible than the current pci-netif.c code.

    The code only enables I/O decoding if the flag PCI_USES_IO is passed.
    (Normally it is either PCI_USES_IO or PCI_USES_MEM.) The video drivers can
    use the scan code to map in memory ranges, or even overlapping I/O ranges,
    without activating PCI I/O space.

    > I'm very interested in comments on the patch sent to you. I probably
    > need a drv_unregister in order to support CardBus. And I like your
    > handling of pciaddr/ioaddr, but that needs to be extended to support
    > multiple regions, and different schemes of using ioremap().

    NNnnnnoooooo....

    You have missed the point -- it's not supposed to be an overdesigned
    abstraction layer that handles every theorized combination. It's supposed
    to be a clean utility for real-life hardware, the vast majority of which
    needs only a single mapping and an IRQ. If it's more complex than that, it's
    likely to be so much more complex that it would require an elaborate
    description language.

    > 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. */
    >
    > It is incredibly useful for video cards, and I'm thinking for my
    > framegrabber driver too. Easy sub-allocation of PCI resources is made
    > possible by the new scheme.

    It's over-engineered. It's an abstraction layer where there should be
    none. It abstracts out the essential differences, thus everyone must learn
    both the abstraction and the underlying details.

    A device driver writer needs to know addresses, the exact semantics of bus
    operations, and where the bits are going. Having everything be an abstract
    resource just makes life difficult.

    These chunks of code we are talking about are just utilities. They should
    make device drivers smaller and more approachable. In turn device drivers
    shouldn't be complete languages for describing every possible feature of a
    device. They should be the minimal code for setting up hardware to move
    bits around in a standard way for the OS. And to tie this into a favorite
    flame, the application user scanning the web for porn or bidding for beanie
    babies on eBay doesn't care that your OS allows building elaborate
    per-process viewpoints of the file system.


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

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