[linux-audio-user] realtime-lsm in the kernel

[Luke Yelavich]

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