Subject: Re: [linux-audio-user] realtime-lsm in the kernel
From: Luke Yelavich (luke_AT_audioslack.com)
Date: Wed Sep 08 2004 - 02:27:29 EEST
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_AT_audioslack.com
This archive was generated by hypermail 2b28 : Wed Sep 08 2004 - 02:34:50 EEST