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.069 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site