Messages in this thread | | | Date | Tue, 11 Jul 2000 02:38:58 +0400 (MSD) | From | Khimenko Victor <> | Subject | Re: [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/
| |