|To:||Donald Becker <becker@xxxxxxxxx>|
|Subject:||Re: pci-skeleton duplex check|
|From:||Jeff Garzik <jgarzik@xxxxxxxxx>|
|Date:||Fri, 13 Dec 2002 15:57:51 -0500|
|Cc:||Roger Luethi <rl@xxxxxxxxxxx>, netdev@xxxxxxxxxxx, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202|
Donald Becker wrote:
On Thu, 12 Dec 2002, Jeff Garzik wrote:
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.
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.
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
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.
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.
|<Prev in Thread]||Current Thread||[Next in Thread>|