lkml.org 
[lkml]   [2003]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ptrace hole / Linux 2.2.25
> akpm has suggested something like this in the past.  I respectfully
> disagree.
>
> The 2.4 kernel will not benefit from constant churn of backporting core
> kernel changes like a new scheduler. We need to let it settle, simply
> get it stable, and concentrate on fixing key problems in 2.6. Otherwise
> you will never have a stable 2.4 tree, and it will look suspiciously more
> and more like 2.6 as time goes by. Constantly breaking working
> configurations and changing core behaviors is _not_ the way to go for 2.4.
>
> I see 2.4 O(1) scheduler and similar features as _pain_ brought on the
> vendors by themselves (and their customers).

O(1) sched may be a bad example ... how about the fact that mainline VM
is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
for that have been around for ages.

The real philosophical question is "what is mainline 2.4 _for_"?

> Surely it is better to concentrate developer time and mindshare on making
> 2.6 sane?

Agreed, but all we're doing now is burning lots of time on backporting
stuff from 2.5 into each separate distro base, and each distro fixing
things independantly in their own tree (eg O(1) scheduler). I don't
see that as constructive ... customers will not stagnate, and I don't
see the point in 2.4 mainline doing that either.

It's now got to the point where the testing people don't even bother
testing mainline 2.4 because they know it's horribly broken, and is not
getting fixed, so there's no point. I think that's sad. Instead, we test
umpteen different vendor kernels, and try to apply the same fixes to each
of those, which is a pain in the butt, becasue they won't merge cleanly
because the trees are so far diverged. People running non-vendor kernels
are generally running 2.4-aa or 2.4-ac, etc, etc. All burnt thrash time.

Yes, the real answer is to get 2.6 out the door, and move people onto it.
But that will take a little while ... would be nice to get some way to
alleviate the pain in the meantime.

M.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.151 / U:1.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site