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


    On Mon, 10 Jul 2000, Jesse Pollard wrote:

    > "Khimenko Victor" <khim@sch57.msk.ru>:
    > > In <20000710092651Z32202-532+21297@nic.funet.fi> Juhana Sadeharju (kouhia@nic.funet.fi) 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
    kernel.

    > 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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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