| |||||||||||||
|
| |||||||||||||
Quote of the weekQuote of the weekPosted Oct 12, 2006 13:40 UTC (Thu) by ebiederm (subscriber, #35028)In reply to: Quote of the week by dougg Parent article: Quote of the week
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.
(Log in to post comments)
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.
|
|
||||||||||||