Re: [tlug] Just curious... how much impact does a kernel update make?

[Edward Middleton <emiddleton@example.com>]

Stephen J. Turnbull wrote:
> Also, I offer some hearsay for your consideration (I can't confirm it
> and don't have a cite).  That is, the current way the kernel is stuck
> on 2.6 is partly due to vendor politics.  In the 2.4->2.6 transition
> they had a lot of trouble getting customers to upgrade because a minor
> version bump was considered too risky.

This is spot on.  But it was more then just that,  a lot/most companies 
choose to develop directly for 2.4 (which they could sell to customers) 
and ignored 2.5 kernels completely.

  By pushing the activity back
> to the micro version, they had a lot more luck, even though some of
> the changes were big enough that (together) they probably would have
> justified a minor bump.  Also, this made the kernel developers happy,
> because more people were trying their new features earlier, thus
> giving them more timely feedback.  The only people who aren't so happy
> are module developers, who see more frequent API changes than they
> were used to (Ian Wells commented on this).

You probably want to make the distinction between in tree and out of 
tree module developers.  Last time I checked, making kernel level 
architectural that broke existing modules (which has occurred in 2.6 
kernels) required all in tree modules to be ported to the new 
architecture before the change was accepted.  If you are a module 
maintainer you would obviously have to test that the changes actually 
worked but the onus would still be on the person making the change to 
fix what they break.

>  > Of course, different developers all have differing motivations for
>  > using version numbers. But if my above analysis is generally
>  > applicable, then it would seem to me that the Linux kernel
>  > developers pretty much think that the kernel does exactly what it
>  > needs to do, and only needs maintenance in the form of minor
>  > adjustments for new hardware and the like.
>  > 
>  > Does that sound like a reasonable take on it?
>
> I would disagree.  In upgrading from 2.6.20.7 to 2.6.27.1, I saw about
> two dozen new kernel, not driver, features.  Mostly they were small,
> such as variations on how NUMA architectures are handled, but others
> offered changes in how scheduling etc is done.  As Ian Wells said,
> this kind of complexity-increasing change carries risk of regressions.
> They're not minor maintenance.

Well it depends on how you look at it.  In terms of user visible 
changes[1] Dave's assessment is pretty close.  This is of course a good 
thing because user visible kernel changes generally mean user level 
application changes are necessary.

User level application are fundamentally different from kernels.  The 
primary users of KDE are people.  The primary users of kernels are 
programs.  As inflexible as people may be, we are still far more 
flexible then programs.  If our kernel was running through major version 
changes at the rate that KDE does then most applications wouldn't run on 
the latest version, and we would still probably all be using 2.6 ;)

Edward

1. When I say "user visible changes" I am talking about fundamental 
changes not addition of new drivers or performance improvements etc.