Re: realtime kernel for Debian
Adrian Knoth wrote:
I asked an guy who did some work on the RT kernel for Ubuntu. This is
what he said:
On Wed, Mar 25, 2009 at 12:37:37PM +0100, Grammostola Rosea wrote:
What is true about this? Shouldn't plain Debian also support those Pro
audio Firewire devices, the ones the FFADO team are making drivers for?
What's good for Debian is good for us :-) but the Debian project may
not want to tweak the kernel or the FireWire stack just for the
benefit of FFADO users. In the 64 Studio project we have more
flexibility to do things like that.
Why only in 64studio and not in plain Debian?
Some background info here:
Compile both modules and blacklist the new Juju modules. That's the
current upstream recommendation.
Even if the default will change around 2.6.30 (or later, I don't know
the exact schedule), the FFADO users could still enable the old ieee1394
We already have libraw1394-v2 in sid, but as outlined, FFADO currently
only works with the old stack. This might also change in the future,
especially if the Google Summer of Code project succeeds. (in-kernel
alsa driver module for firewire audio)
IOW: ship both stacks, decide for one and blacklist the other. FFADO
users will then select the appropriate one. And of course, I'll continue
looking into the FFADO-on-Juju issue.
1) Ubuntu RT kernel don't offer the same guarantees that offer one of
the Debian kernels. For example DOS vulnerabilities are accepted into
Ubuntu RT Kernel (because it live in universe) when in Debian aren't
accepted at all.
2) Kernel packages between Debian and Ubuntu are very different.
Different version, different build infrastructure, different approach
in accepting external sources. These packages are one of few packages
that Ubuntu don't inherit from Debian.
3) Lenny is just released. I suppose that the next Debian release will
probably be in two years. In meanwhile it is probably that almost rt
bits will be merged and available in vanilla kernel (when it happen
the rt kernel could became one of all kernel flavours that Debian
In other words a lot of effort is required for satisfy high quality
requested by Debian policy.
Comments on this?