[lkml]   [2000]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-audio-dev] lowish-latency patch and toolchain

    On Mon, 10 Jul 2000, Jesse Pollard wrote:

    > "Khimenko Victor" <>:
    > > In <> Juhana Sadeharju ( wrote:
    > >
    > > > I think 4 ms could be better. If we don't get any agreement we really
    > > > should go for the old 2 ms lowlatency patch and forget any new compromized
    > > > kludge.
    > >
    > > > It would be nice if Linus would allow keeping this kludge patch as
    > > > compilation option in Linux source tree, so that it comes with every
    > > > Linux distribution. That would be __a real compromize__!
    > >
    > > Huh. You joking, right ? Low-latency patch was not accepted since it'll make
    > > kernel maintainance nightmare (this not the only reason, but main reason).
    > > And this patch as kernel compilation option will affect kernel maintainance
    > > MORE not less then just patch without compilation option. THIS IS "a real
    > > compromise" ??? Gah.
    > I thought he may mean an option that would apply the patch to a normal
    > kernel. That way the patch would be matched against the distributed kernel,
    > but the kernel would NOT have the patch already applied.

    And what it's changing ?

    > This would have eliminated the "will affect kernel maintainance" reason,

    Yeah ? What's the difference: you should keep kludges spread around
    kernel up to date, ifdef's or separate patch ? All choices requre more
    or less the same amount of work for kernel developers (IMHO most simple
    one is first choice BTW).

    > and would not be any worse than the user having to download the patch, apply
    > it, and build.

    No. It would be worse: if user downloaded patch and patch is rejected it's
    NOT kernel maintainer headache but user's (or patch maintainer's :-)
    headache. When you are using something distributed with kernel you EXPECT
    it to apply cleanly unlike separate patch.

    > It would, at least, promise that the patch would apply correctly
    > (without patch errors),

    Yes and there exist ONLY ONE way to guaratee this: maintain patch just
    like it was adopted and included in kernel. Where is the win ?

    > and the resulting kernel should (but not always) run.

    If it does not run then why patch is there in first place ? You can do it
    yourself without problems. Just do
    -- cut --
    patch <patch options here>
    find -name '*.rej' -o -name '*.orig' -print0 | xargs -0 rm -f
    -- cut --
    But if you want manual change of patch so it'll reflect kernel changes
    it's called maintainance and is MORE difficult for patch then for part of

    > A most "experimental" option ever.

    See above.

    P.S. Have you EVER maintained non-trivial patch for any program ? I did.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.020 / U:7.296 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site