Messages in this thread | | | Date | Sat, 11 Sep 1999 06:41:15 -0400 (EDT) | From | Donald Becker <> | Subject | Re: [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 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/
| |