| |||||||||||||
Quote of the weekQuote of the weekPosted Oct 12, 2006 13:15 UTC (Thu) by dougg (subscriber, #1894)Parent article: Quote of the week
David seems to forget that there are thousands of open source drivers "out of tree" because their authors don't have the political clout to get them in, the management thinks they are too obscure, or the management doesn't like them. In the latter group are my favourites: the drivers that bypass the management. A practical consideration is the size of the kernel source tarball: how big is too big?
So why make it difficult for these "out of tree" drivers just to spite some recalcitrant hardware vendors?
(Log in to post comments)
Quote of the week Posted Oct 12, 2006 13:40 UTC (Thu) by ebiederm (subscriber, #35028) [Link] Beyond the obvious: Documentation/stable_api_nonsense.txt
The reason for this change is that this api became very difficult to support on one of the architectures, and that architecture is in tree. In tree code is more important that out of tree code. Plus the argument was unused.
As for the kernel tarball size the last anyone checked it is growing linearly and hard drives are growing exponentially so unless relatively the kernel is getting smaller. Having a driver in tree is actuall less code because you don't need the backwards compatibility cruft so for people needing to maintain things an in tree driver is actually less code and less work because they don't have to search for the driver and the driver they have to read is smaller.
Beyond which people really did work out strategies to keep drivers working on older kernels.
As for political clout to get a driver in, in most cases all it takes is a little bravery. Adding a totally new class of driver is harder but only because it takes new infrastructure and the new infrastructure needs to be discussed.
My favorite suggestion was:
Which makes it trivial to maintain source compatibility on old kernels.
Quote of the week Posted Oct 12, 2006 16:47 UTC (Thu) by william.waddington (subscriber, #25316) [Link] #ifndef __PT_REGS# define __PT_REGS , struct pt_regs *pt_regs #endif
Works for me, but I haven't seen the matching #define __PT_REGS <nothing> in the kernel tree/patches yet. Likely to be forthcoming/already there somewhere, or do I need to work up the nerve to submit a patch?
Quote of the week Posted Oct 15, 2006 13:17 UTC (Sun) by tlw (guest, #31237) [Link] > As for political clout to get a driver in, in most cases all it takes is a little bravery.Either you are making one of the funniest Linux-related jokes I've ever heard, or you are conveniently ignoring and sugar-coating the hundreds of flame wars that take place regularly on LKML. If it were simply a matter of changing an identifier here and moving a comma there I could agree with you. But in most cases trying to submit a driver results in a difference of opinion regarding the design of the submitted code; and the only way to win a design discussion is with large amounts of clout. Is there an empirical way to absolutely prove one design is better than another? Absolutely not. Design decisions are always a matter of personal taste: some designs solve some problems better and other designs solve other problems better. Additionally, when you consider that all these "design discussions (now I'm sugar-coating!)" are done out in the open on mailing lists that are backed-up for all eternity on millions of hard disks around the planet and taking into consideration the large number of these discussions which degenerate into flame wars and name calling (sprinkled with explicatives, to taste)... well, let's just say that takes a whole lot of "bravery". :-) If you want to test my theory please email Linus, CC'ing LKML, and try explaining to him that the Hurd kernel is a much better design than his monolithic kernel. Or email LKML explaining that you've reviewed the design of the ReiserFS and found it better than ext3. Or email GregKH (CC:LKML) informing him that devfs is better than sysfs and therefore it should not be removed from the kernel because you want to continue using it. Just because they say their designs are better doesn't mean they're better for you.
Quote of the week Posted Oct 16, 2006 10:01 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] If it were simply a matter of changing an identifier here and moving a comma there I could agree with you. But in most cases trying to submit a driver results in a difference of opinion regarding the design of the submitted code; and the only way to win a design discussion is with large amounts of clout. No. The way to win a design discussion is with a good design. And thats why your examples about Hurd, Reiserfs and devfs are so clearly bogus. Youre right that there is a large element of personal taste involved. But unless a design is actually bad you wont normally be held ransom to others taste if you can justify your own. One of the good things about Linux development is that it goes largely on the merit of the code, and political clout plays a relatively small part in it.
Quote of the week Posted Oct 12, 2006 16:41 UTC (Thu) by william.waddington (subscriber, #25316) [Link] We have included source with our drivers going back to SunOS 4.1.3 - about the time Linus was coding in his jammies. To the extent possible, we try to protect our users/OEMs from kernel changes, and give them a consistent API. Part of this is a (reasonable) expectation that they can download our latest 2.6 driver (for example) and expect it to play nice with the latest 2.6 kernel as well as earlier kernels in the 2.6 series.
The niche is small, and the drivers of interest only to us and a small group of users and OEMs. The chance of main line inclusion is zero (or maybe a large negative number) due to niche size, and probably coding style...
I wouldn't expect kernel developers to constrain changes for the sake of out-of-tree maintainers, but where simple #define(s) in the kernel tree can help us maintain source-level compatibility (our drivers are intended to be compiled by the user/OEM at initial install) it would be quite helpful.
Quote of the week Posted Oct 12, 2006 19:11 UTC (Thu) by net_bh (guest, #28735) [Link] >The niche is small, and the drivers of interest only to us and a small group >of users and OEMs. The chance of main line inclusion is zero (or maybe a >large negative number) due to niche size, and probably coding style...
For this reason alone, please read Greg-KH's OLS keynote @ http://www.kroah.com/log/linux/ols_2006_keynote.html
Quote of the week Posted Oct 13, 2006 14:13 UTC (Fri) by william.waddington (subscriber, #25316) [Link] "For this reason alone, please read Greg-KH's OLS keynote @ http://www.kroah.com/log/linux/ols_2006_keynote.htmlSomewhere in the middle he talks about exactly your case and why it is still "beneficial to push your code in-tree."
You mean that pushing my code in tree would improve my coding style? No doubt :) Seriously, I'm familiar with Mr. KH's presentation, and I don't really disagree, at least for new driver development.
Even so, there are things about the code that would make pushing in-line a real ordeal: coding style, plethora of ioctls, and DMA directly to/from user buffers, among others. The coding style is fixable, and there are probably "better" ways to handle the API, but "fixing" the API would require abandoning the read/write/ioctl interface we have kept consistent for multiple unixen for 15 years - which seems to be working well for our OEMs and end users.
|
|||||||||||||