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@xxxxxxxxxxxxxx
