Linked by Thom Holwerda on Sat 6th May 2006 17:26 UTC, submitted by JMcCarthy
Linux Andrew Morton, the lead maintainer of the Linux production kernel, is worried that an increasing number of defects are appearing in the 2.6 kernel and is considering drastic action to resolve it. "I believe the 2.6 kernel is slowly getting buggier. It seems we're adding bugs at a higher rate than we're fixing them," Morton said, in a talk at the LinuxTag conference in Wiesbaden, Germany, on Friday.
Thread beginning with comment 121804
To read all comments associated with this story, please click here.
RE[2]: Million times
by kaiwai on Sun 7th May 2006 04:06 UTC
kaiwai
Member since:
2005-07-06

Sounds like a recipe for even more issues! Unless I am not understanding your point... ;)

If I am wrong, please clarify, because your post isn't making much sense as it appears to be written.


The problem is, the original author jumps from wanting a stable driver API to providing an API which can allow him to load Windows drivers.

Lets address the first issue; in the case of the WDM - Windows Driver Model, the new model which was introduced in Windows 9x, which was meant to span from 2000 to Windows 9x - which has then be split into two parts, there is the driver for hardware and the driver for the display.

Both would require substantial modifications to the kernel and X11 server just to get it up and running, and even then, you'll be stuck in a situation whether its actually worth all the trouble given the alternative.

The alternatie is a stable API, but to provide a stable API, not only does it require them to establish a concrete API but to also provide backwards compatibility when they fix up something - everytime Microsoft fixes up something on Windows, not only do they have to fix the problem, but provide a work around, a 'mock broken functionality' as to allow those companies who relied on the broken feature, for their software to continue running - this will be the same situation with Linux.

Also, lets just say tomorrow Linus comes out and announces a brand new stable API - the problem won't go away as each distribution is compiled with a different compiler, incompatbility between compilers also exists as well.

Until GCC come up with a stable ABI and Linux comes up with a stable API, the problems aren't going to be magically fixed over night via the scream of 'I need a stable API!".

Reply Score: 5

RE[3]: Million times
by stephanem on Sun 7th May 2006 04:10 in reply to "RE[2]: Million times"
stephanem Member since:
2006-01-11

Also, lets just say tomorrow Linus comes out and announces a brand new stable API - the problem won't go away as each distribution is compiled with a different compiler, incompatbility between compilers also exists as well.


Bingo, you just have to round up the GCC guys and threaten them with a trip to Gitmo if they don't wisen up and stop fscking around with REGPARM/NoREGPARM, 4KSTACKS/8KSTACKS and other basic binary incompatibilities.

I'm sure that MIT has a good course on Compilers and FSF offices are a stones throw away.

Reply Parent Score: -1

RE[4]: Million times
by gilboa on Sun 7th May 2006 11:14 in reply to "RE[3]: Million times"
gilboa Member since:
2005-07-06

What does 4KSTACKS has to do with GCC?

G.

Reply Parent Score: 2

RE[3]: Million times
by Brendan on Sun 7th May 2006 08:16 in reply to "RE[2]: Million times"
Brendan Member since:
2005-11-16

Also, lets just say tomorrow Linus comes out and announces a brand new stable API - the problem won't go away as each distribution is compiled with a different compiler, incompatbility between compilers also exists as well.

Are you sure about this? How many times have you changed your kernel configuration and found that most of your applications are broken?

All sane "API specifications" include calling conventions. That's why your applications don't break when you modify the kernel, and that's why all compilers can support the stable API.

There's only 2 "valid" problems with creating a stable API for device drivers. The first problem is the GPL/open source mentality, where it's not "fashionable" to allow other peoples work to be closed source. The second problem is backwards compatibility, which can be solved in a number of ways.

The normal way to solve the backward compatability problem is to have "OS versions", where the API can change between versions. For example, "Linux 2.9.x" could use "driver API version 2.9", while "Linux 2.10.x" could use a (possibly completely different) "driver API version 2.10". In addition, "Linux 2.10.x" could also support the old "driver API version 2.9" (but this old API could be dropped in "Linux 2.11.x", which limits the amount of backwards compatibility). This is how Microsoft do it (although they only release a "new version" every 8 years or something).

Another way would be to allow new API functions to be added at any time, and allow old API functions to be removed after a warning period - a device driver that works now might generate "API function 0x1234 is deprecated" warnings for 12 months and then might stop working after that.

The last way would be to ditch the buggy "mega-beast" and switch to a micro-kernel (there was an article about this)... :-)

Reply Parent Score: 2