Linux-kernel mailing list archive 1999-36,: Re: [patch] pci probing

# Re: [patch] pci probing

Donald Becker (becker@tidalwave.net)
Sat, 11 Sep 1999 06:41:15 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: David Weinehall: "Re: 2.3.18-ac1: double_lock() moved into <include/linux/dcache.h>"
- Previous message: David S. Miller: "Re: linux threads vs. solaris threads"

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
change.

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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: David Weinehall: "Re: 2.3.18-ac1: double_lock() moved into <include/linux/dcache.h>"
- Previous message: David S. Miller: "Re: linux threads vs. solaris threads"