On Wed, Sep 08, 2004 at 09:14:21AM EST, Malcolm Baldridge wrote:
Now that the
final touches are being put on the 2.6 low latency patches,
a massive migration of linux audio users to 2.6 is imminent.
Really? Is this even wise or safe?
It looks like things have barely gotten to the "It seems to work" stage, let
alone made it through the "It doesn't crash too often" or "I
haven't lost
data with it lately" stages of validation.
There's nothing in 2.6 that's required for a reliably running 2.4-based
setup. If Linux Audio users are interested in actual recording and music
production, I think you might be better off steering them towards a known
safe and proven solution, rather than a series of patches which are still
steaming from their maker's keyboard.
I agree. I personally won't be shipping 2.6 kernels for my repository until
Slackware ships a 2.6 kernel out of the box, although I will make kernels with
these patches available for testing, so if a user breaks something, it is not
my problem.
It's easy to mistake the rapid pace of linux
kernel development and
translate for actual "release grade" software, but this is a dangerous
fallacy. A newbie user is the worst beta-tester for this kind of maverick
kernel which has not received even a month of hardcore stress-testing and
the time for it to percolate to a large number of systems out there in
linux-land.
Hense the need for 2.6 kernels to be made available, but only for testing, so
problems can be worked out quicker and stability can be increased.
Anyway if the
author does not object, I would be willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
Good luck. Generally, the Linux Kernel maintainers tend to focus on the
patch and what it does to the kernel rather than take a popularity poll for
its introduction. Robert Love was successful in getting the preemptible
stuff into 2.6 because his patches were generally clean and separable. They
leverage already-existing locking code for SMP and enlarged their scope to
preemption, so there was very little messing around with drivers, and the
rules for kernel locking didn't change. Generally, if it was an issue for
SMP, it was an issue for preemption.
From a packager's point of view, having this patch
in the kernel does save some
work, but it is certainly no big a deal to build and
ship separately.
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com