2.3.51 tulip broken

[Martin Mares]

Hello, world!

> That's complete BS, as you more than anyone knows.  I'll recap recent history:
> 
> Just few months ago I finished the design on a new probe routine that
>    Made it easy to maintain driver that would work on kernels back to 1.3.*.
>    Made it possible for a single driver to work with PCI, CardBus, and
>     hot-swap PCI.
>    Handled power control and Wake-On-*.
> 
> That work took several months to complete, during which time incremental
> versons of many driver were readily available using the frequently-changing
> interface.
> 
> Just as I finished that work, YOU proposed a "much simpler" PCI scan
> routine, calling mine too complex.  Based on the much smaller patch, that
> version went into the kernel...  discarding months of my work and testing.
> 
> Since then your PCI scan interface has changed many times, to the point that
> it's more complex than mine.  It had to, because the issues were the same.
> My years of experience writing CardBus-compatible drivers meant that I knew
> the issues up-front.  AFAIK, you hadn't written a single CardBus or
> hot-swap-PCI driver when you proposed your scan routine.

   Donald, you have my great respect and I deeply appreciate that you've
done for Linux much more that I ever did, but I think that in this case
your view is very distorted. First of all, speaking of PCI scan interface
changes, Jeff is completely innocent -- all the changes were done by me
and I think that after maintaining the Linux PCI layer for more than two
years I'm not a completely clueless person.

   I'm sure you remember my comments on your code I've sent you several
months ago. Your PCI probing code wasn't too complex -- it's relatively
simple, but it's surely not generic enough to allow it to be used by all
the PCI drivers. The interface I've designed is actually a functional
superset of yours, allows to write a single driver handling PCI, hotplug
PCI and CardBus devices with a single piece of code and some aspects of it
(__devinit, __devexit etc.) transcend the PCI world and are applicable
on any bus with hot-pluggable devices.

   You also speak about frequent changes of the kernel PCI API and I think
it isn't fair -- ignoring intermediate versions when the particular API
was being developed (where you cannot expect it to be stable for some time,
there exist three different API's:

	- The ancient one (pcibios_* functions, refering to devices
	  by bus+devfn numbers).

	- The 2.2 one (pci_* functions, using struct pci_dev * everywhere)

	- The 2.3/2.4 one (resources, pci_register_driver etc.)

You might say that three different API's are a way too much, but I think
that they aren't -- more than six years of PCI development with the world
you're trying to adapt to changing so fast cannot be covered by a simpler
set of API's unless you are really clairvoyant. The 2.2 API has brought
us reasonable PCI support on non-PC architectures, the 2.3 one brings
support for real resource management and hot-pluggable devices.

> To you such an interface change is a minor tweak that can be with an
> automated search-and-hack.  What takes you only a minute per file to change
> might take the developer hours over the next few months to deal with to
> integrate with testing.  This is especially true when Linus insists that all
> traces of 2.2 support be expunged in the 2.3 drivers.

   Simple development of drivers for all actively used kernel versions
is surely important, but it should not be the primary goal of development
of new interfaces unless you want to have an OS full of compatibility
glue and misdesigned interfaces. The reality gives OS designers still
new challenges and it's impossible to design internal kernel API's
which will cover all future hardware in an elegant way. You can either
produce still more and more complex variants of the original API making
everything long, slow and hard to maintain or sometimes do a big bang,
design a new API and convert the drivers. Linus has decided for the latter
and I agree with him that it's the only way to keep the kernel
maintainable.

   On the other hand, it doesn't mean you cannot design drivers working
with multiple kernel versions -- you can still keep your pci-netif
design (and adapt it to the new kernel API; actually I remember I've
offered you I'll do that if you want) or even better write a compatibility
wrapper which will add the new PCI functions to older kernels.

> There were many interface changes added incrementally in the 2.3 kernels.
> Some with added without consideration of, or even in opposition to,
> cross-version compatibility.  And few of those interface changes were
> designed, as opposed to just hacked in.  When I proposed an new PCI
> detection interface I wrote a skeleton driver, converted several of my
> drivers, demonstrated that it worked with several hardware classes and wrote
> a usage guide.  But the few day hack was added because the patches were
> incremental (even if misdesigned and broken).

   When saying such things, please at least look at the kernel patches!
When adding the new PCI API, I've tested it on the tulip_cb driver
and wrote documentation (see Documentation/pci.txt in kernel tree)
about how to use it. Other people didn't start using it before it
was tested and proven to be stable.

   Also, please don't blame us for not cooperating with you when
designing the new kernel interfaces. Since the stone age of Linux,
such things are being discussed on the linux-kernel mailing list
and it's generaly expected that people interested in interface
changes watch this list and comment the proposals.

				Have a nice fortnight
-- 
Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/
"Press any key to quit or any other key to continue"
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org