lkml.org 
[lkml]   [2006]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Development tree, PLEASE?
    On Thu, Feb 02, 2006 at 11:25:24AM -0700, Michael Loftis wrote:

    > >o You want security fixes and only minor other fixes (done magically
    > > by someone else as you're not willing to pay for it, nor are you
    > > willing to help yourself), for at least 6 months, but you ignore
    > > the existance of the 2.6.x.y kernel series, which does exactly
    > > that -- check
    >
    > There's noone out there that does that, I'd LOVE to be able to pay for it
    > and not have to do it myself. RedHat kernels don't work on most of our
    > gear

    Specifics? The patches we carry in Fedora aren't very system-specific,
    so any failure to boot there would likely be a problem on mainline.
    The "but it works on $otherdistro" response that seems to be so popular
    these days is time after time proven due to be because $otherdistro is
    shipping an older kernel, and hasn't hit that particular bug yet.

    > , and RH, up to and including fedora core, and centos have some 'great'
    > issues, like the listener processes for Apache and MySQL using up *ALL* of
    > the system CPU when *NOTHING* is happening.

    How did you determine this is a kernel bug? Did you file a bugzilla report on this?

    > We've tried to track it down,
    > it's gotten to where we just don't care and we just don't deploy RedHat
    > anymore. SuSE's kernels suffer the same problem of too many patches I
    > mentioned before for totally unrelated, non-security things.

    You can't complain about 'too many patches' in a distro kernel these days.
    Any distro that ships a stock vanilla kernel is a distro that has
    known oopsable drivers, features that don't work as expected,
    won't boot on certain hardware, and other general flakyness.

    In the current FC4 2.6.15.2 based update..

    - 47 bug fix patches. Shipping without these isn't an option.
    - 24 'deviation' patches, where we add some not-yet-upstream feature
    or rh-specific feature. (Xen, Execshield, signed modules, restricted /dev/mem etc)
    [note, not 1 diff per feature, some features are multiple patches]
    - 21 debugging patches. (Enabling extra output in certain bad situations etc)
    - 3 convenient 'make the buildsys life easier' patches
    - the remainder are other 'nice to haves' backported from 2.6.16rc

    At the absolute minimum, we'd need to carry those 47 bugfixes.
    Some of these get pushed to -stable, some aren't considered enough
    of a problem, so they'll sit there until I rebase to a .16

    We have this mentality in certain circles of "I don't want any
    changes in my distro kernel, oh, except for ones that I want".
    The problem is when >1 person wants patches to make their systems
    run, the result is a pretty large collection of patches.

    If you want a kernel with a limited set of patches, the only answer
    is 'build your own', but don't complain about vendors doing the
    only thing that they can do that they've been doing for the last
    10-15 years -- Trying to make a single kernel image work on
    as many platforms as possible with the smallest amount of pain.
    (And 'new' development model hasn't changed a damn thing in this regard,
    it's always been a challenge).

    Dave

    -
    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: 2006-02-02 21:13    [W:4.238 / U:1.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site