Re: 2.6.16-rc4: known regressions

[ebiederm@xmission.com (Eric W. Biederman)]

Greg KH <gregkh@suse.de> writes:

> On Wed, Feb 22, 2006 at 08:29:48PM +0100, Arjan van de Ven wrote:
>> On Wed, 2006-02-22 at 11:18 -0800, Greg KH wrote:
>> > What about trying a stock 2.6.6 or so kernel?  Does that work
>> > differently from 2.6.15?
>> 
>> ... however it's very much designed only for the kernel that comes with
>> it (with "it's" I mean all the userspace infrastructure); all the
>> changes and additions since 2.6.9 aren't incorporated so you probably
>> really want new alsa, new initscripts, new mkinitrd, new
>> module-init-tools. some because of abi changes since 2.6.9, others
>> because the kernel grew capabilities that are really needed for "nice"
>> behavior.

Not being able to take advantage of the latest whizz bang features
sound sane.  Kernel ABI changes do not sound sane.

> I totally agree.  Distros are changing into two different groups these
> days:
> 	- everything tied together and intregrated nicely for a specific
> 	  kernel version, userspace tool versions, etc.
> 	- flexible and works with multiple kernel versions, different
> 	  userspace tools, etc.
>
> And this is a natural progression as people try to provide a more
> complete "solution" for users.

Huh? I can understand it from the rational of a support contract, 
limiting the number of possibilities you have to deal with.  Beyond
that it just seems ludicrous.  If something is relied up by user
space it should be stable enough that you can upgrade your kernel.

It should be a case of not-supported but it ``should'' work.  So
anyone who is competent enough to do kernel development should 
have no problem getting things going.

> When people to complain that they can't run a "kernel-of-the-day" on
> their "enterprise" distro, they are not realizing that that distro was
> just not developed to support that kind of thing at all.

Which is a really bad tack to take.  It seriously forks the kernel
debugging and testing efforts.  Even with a distro that only wants
to support one kernel if people are having kernel hardware interaction
problems I will still suggest that they upgrade their kernel to
see if the problems are fixed in the newer kernels.  If there are
user space glitches but the drivers work, there are a lot more people
who can fix user space than can fix the kernel.

The historic rule is that if you need to know what needs to be changed
you read through Documentation/Changes.  If your distro has something
older you probably need to upgrade if not you don't.

> So, in short, if you are going to do kernel development, pick a distro
> that handles different kernel versions.  Likewise, if you are doing
> userspace development (X.org, HAL, KDE, Gnome, etc.) you pick a distro
> that allows you to change that level of the stack.

But this applies to kernel debugging so having a distro that is tied
intimately to their kernel is a problem for anyone running on recent
hardware.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/