[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, 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

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
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().


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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.106 / U:7.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site