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 121851
To read all comments associated with this story, please click here.
Stable API? Not in the near future.
by gilboa on Sun 7th May 2006 11:43 UTC
gilboa
Member since:
2005-07-06

Ignoring for a second the GPL vs. closed source binary drivers problem, considering the pace in which the kernel is being developed now-days it'll be a shame to halt the development for a year or two, spending every available resource on a stable in-kernel API considering (what-I-see-as) marginal effect on stability.

Being a in-house driver developer for my workplace, I share the grief of having the kernel constantly change under my feet. However, I rather have a fast evolving development platform, then have a slow moving kernel, trapped with ill-designed, out-date interfaces that that consume huge amount of resources required to maintain it, all in-order to preserve compatibility with old closed source drivers.

Other then that:
1. The Linux (kernel) is a fast moving target and will remain as such for the foreseeable future. Like it or not, the in-kernel API will remain unstable.
2. Most of the kernel bugs I've witnessed had nothing to do with the kernel API; most of them were plain old module bugs/problems. A changing the kernel API will mostly break module compilation; beside regparam/4K stacks, I never -personally- witnessed an API change that caused a in-tree kernel/module to break. (come to think about it, most of the casualties of 4K/regparam were closed source/out-of-tree modules to being with).
3. If one designs a out-of-the-main-kernel-tree module/driver/etc (open or closed), it's his responsibility to maintain it as the kernel tree moves.
4. The price of having a stable in-kernel API is too expensive considering it's marginal effect on the kernel stability.

G.

Reply Score: 3

gilboa Member since:
2005-07-06

... And 120 seconds after I posted the above, I tried compiling my module against FC5's latest 2.6.16 kernel just to find out that d_node semaphores have been replaced...
Oh... The joys of living on the bleeding edge ;)

Reply Parent Score: 1

Cloudy Member since:
2006-02-15

However, I rather have a fast evolving development platform, then have a slow moving kernel, trapped with ill-designed, out-date interfaces that that consume huge amount of resources required to maintain it, all in-order to preserve compatibility with old closed source drivers.

But that's a false dichotomy. I'd rather have a well thought out slowly changing API with backward compatibility for open source drivers than either of your choices.

"fast evolving" would be more interesting if Linux was doing anything more than evolving to where other systems have been for decades.

Reply Parent Score: 2

gilboa Member since:
2005-07-06

But that's a false dichotomy. I'd rather have a well thought out slowly changing API with backward compatibility for open source drivers than either of your choices.

I doubt that it's doable in the foreseeable future.

"fast evolving" would be more interesting if Linux was doing anything more than evolving to where other systems have been for decades.

If you consider where Linux 1.0 and GNU were ~10 years ago and compare that to Windows NT 4.0 - and then take Windows XP and compare that to linux 2.6 and KDE 3.5.2, you'll fully understand my point.
Linux is a young kernel; GNU is a young platform. It has yet to find it's bullet bullet when it comes to kernel and in-kernel API design and as such, it must not be locked into current APIs. (Which were invented as you go).

Oh... and considering the number of servers running GNU/Linux based distributions (Considering Microsoft's seemingly infinite marketing and development resources, let alone their market dominance), GNU/Linux must be doing something right... (As volatile as the in-kernel API is.)

G.

Reply Parent Score: 1