Messages in this thread | | | Date | Wed, 22 Feb 2006 21:45:08 +0100 | From | Jens Axboe <> | Subject | Re: 2.6.16-rc4: known regressions |
| |
On Wed, Feb 22 2006, Greg KH wrote: > 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. > > 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. > > Distros in the first category are the "enterprise" releases (RHEL, SLES, > etc.), as well as some consumer oriented distros (SuSE, Ubuntu, Fedora > possibly.) > > More flexible distros that handle different kernel versions are Gentoo, > Debian, and probably Fedora. > > And this is a natural progression as people try to provide a more > complete "solution" for users. > > 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.
I have to disagree somewhat violently to that statement, I'm afraid :-) At least for me, it's pretty much a requirement that I can put eg 2.6.18-rc2 on an enterprise install. It's a must to debug problems - both ways, actually, testing both a new rc kernel on that enterprise distro but also putting a vanilla kernel on the enterprise distro to test something that fails with the distro kernel.
I'd absolutely hate if we got into a situation where you couldn't just put a new vanilla kernel on SLESx. Calling it a complete solution to just sounds like an excuse for breaking things that we don't have to. Please lets not make things so fragile!
> 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.
Everything doesn't fit into those two boxes.
-- Jens Axboe
- 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/
| |