Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: Khimenko Victor (khim_AT_dell.sch57.msk.ru)
Date: Tue Jul 11 2000 - 01:38:58 EEST
On Mon, 10 Jul 2000, Jesse Pollard wrote:
> "Khimenko Victor" <khim_AT_sch57.msk.ru>:
> > In <20000710092651Z32202-532+21297_AT_nic.funet.fi> Juhana Sadeharju (kouhia_AT_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.
This archive was generated by hypermail 2b28 : Tue Jul 11 2000 - 02:11:34 EEST