[[ I don't know why I bother. The people that now control what
goes into the kernel would rather put in random patches from
other people than accept a correct fix from me. ]]
I'm sure you'll continue making snide comments on every mailing list you
maintain, but the fact remains:
I would much rather accept a fix from you.

Perhaps we have a different idea of "fix".

You want are looking for a patch to modifications you have made to code
I have written. In the meantime I have been providing working code, and
have been updating that code to work with new hardware. So a fix is the
working, continuously maintained version of the driver.

To put an admittedly simplified spin on it, you are saying "I want you
to tell me what I have broken when I changed this", and to continuously
monitor and test your changes, made for unknown reasons on a very
divergent source base.

No, that's not it at all.

I would ecstatic if you even posted the changes made to your own drivers
to netdev@xxxxxxxxxxx or similar...

I'm asking for _any_ contributions at all. The more fine-grained the
better...

The drivers in the kernel are now heavily modified and have significantly
diverged from my version. Sure, you are fine with having someone else
do the difficult and unrewarding debugging and maintenance work, while
you work on just the latest cool hardware, change the interfaces and are
concerned only with the current kernel version.

While I disagree with this assessment, I think we can safely draw the
conclusion that the problem is _not_ people ignoring your patches, or
preferring other patches over yours.

I can point to specific instances. Just looking at the drivers in the
kernel, it is clear that this has happened.

There is an admitted preference to people who actually send me patches.
That sometimes translates to "other change" being preferred over logic
in one of your drivers.

I would still greatly prefer patches from you, however. And your
comments on other people's patches are very welcome [and there have been
plenty of those in past -- thanks].

But it existed before, and was discarded!
Yes, the kernel is now _returning_ to a stable state while making
improvements. But there was a period of time when interface stability
and detailed correctness was thrown away in favor of many inexperienced
people quickly and repeatedly restructuring interfaces without
understanding the underlying requirements.

I could mention VM, but I'll go back to one that had a very large direct
impacted on me: CardBus. CardBus is a difficult case of hot-swap PCI --
the device can go away without warning, and it's usually implemented on
machines where suspend and resume must work correctly. We had perhaps
the best operational implementation in the industry, and I had written
about half of the CardBus drivers. Yet my proven interface
implementation was completely discarded in favor one that needed to be
repeatedly changed as the requirements were slowly understood.

But... this is how Linux development works. Believe me, I understand
you don't like that very much, but here is a central question to you:

what can we do to move forward?

The CardBus implementation still fails on some systems, and still wants
work. However, the pci_driver API is not only codified in 2.4.x, but it
is extended to the more generic driver model in 2.5.x. _And_ I have
proven it works just fine under 2.2.x (see kcompat24 toolkit).

What can we as kernel developers do to reintegrate you back into kernel
development? Some of the APIs you obviously don't like, but pretending
they don't exist is not a solution. This is the Linux game, for better
or worse. At the end of the day, if we don't like Linus's decisions, we
can either swallow our pride and continue with Linux, or fork a Linux
tree and make it work "the right way." The driver model (nee
pci_driver) is the direction of Linux.

I would love to integrate your drivers directly, but they don't come
anywhere close to using current kernel APIs. The biggie of biggies is
not using the pci_driver API. So, given that we cannot directly merge

Yup, that is just what I was talking about. Let me continue:

The result is that today other systems now have progressed to a great
implementation of suspend/resume, while Linux distributions now default
to unloading and reloading drivers to avoid various suspend bugs. And
when the driver cannot be unloaded because some part of the networking
stack is holding the interface, things go horribly wrong...

You might be able to naysay the individual details, but the end
technical result is clear.

That's what is currently in development in 2.5.x: sane suspend and
resume. I would dispute that other systems have a decently designed
suspend/resume -- that said, working is obviously better right now than
non-working but nicer design ;-)

your drivers, and you don't send patches to kernel developers, what is
the next best alternative? (a) let kernel net drivers bitrot, or (b)
maintain them as best we can without Don Becker patches? I say that "b"
is far better than "a" for Linux users.

Or perhaps recognizing that when someone that has been a significant,
continuous contributer since the early days of Linux says "this is
screwed up", they might have a point. When Linux suddenly had thousands
of people wanting to submit patches, that didn't means that there were
more people that could understand, implement and maintain complex
systems.

Shit, dude, _I_ recognize this. Probably better than most people, since
I see on a daily basis the benefits of your overall design in the net
drivers, and want to push good elements of that design into the kernel
net drivers. At the end of the day you'd be surprised how much I wind
up defending your code to other kernel hackers, and educating them on
why -not- to do certain things.

IMO the bigger sticking point is - at what point do you say "yeah,
2.4.x/2.5.x APIs may suck in my opinion, but they are the official APIs
so I will use them"? There are tons of reasons why Red Hat (my current
employer) is very leery of taking patches which will not eventually find
their way to the mainline kernel.org kernel. A lot of those reasons
apply in the case of your drivers, too. Using non-standard APIs has all
sorts of software engineering implications which wind up with a negative
developer and user experience.