Ubuntu Studio, -rt and 2.6.27

Ben Collins ben.collins at canonical.com
Tue Sep 2 16:42:41 UTC 2008

Cory K. wrote:
> Please excuse me if I can't speak with as much technical aptitude as I
> would like. I'm simply trying to stimulate conversation.
> Ok. There have been a couple of reasons why the -rt kernel has had
> issues this cycle.
>     * Alessio has had to fight upstream for support of .26.
>     * This work has landed late in the cycle.
>     * Alession has had personal issues.
>     * There has been a perceived lack of help from the kernel team to
>       deal with how the kernels are done now. (I cite no response to
>       this thread:
>       https://lists.ubuntu.com/archives/kernel-team/2008-August/002871.html)

I believe I had told you or Alessio that lrm was moving to dkms, which 
means it wouldn't be necessary. Lrm should not be considered a blocker 
for -rt, since the drivers in it are, for the most part, supported in 
stock kernel anyway. Nvidia and fglrx are separately packaged using dkms.

>     * We have now moved to 2.6.27

Irrelevant. The -rt kernel was delayed well before we made this move. 
This may delay it further, but it in no part brought -rt to the issues 
it is trying to resolve right now.

>     * The kernels are managed different in this cycle.

I had stated to you and Alessio that if he were to provide a patch, I 
would help with the packaging end of it. That was never done.

> I am not at all saying this the kernel teams fault. This is an
> unfortunate combination of events. There was also no response to this:
> https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026184.html I
> think, in part, because Alessio can't provide a patch against .27.
> (Again, not the kernel teams fault)

I didn't want a 2.6.27 patch, I wanted to see his current patch so we 
can look at what sort of conflicts and issues we will have trying to 
forward port it.

> So, atm, it *looks* like our only option is to base off of 2.6.26. We
> have a kernel in Universe now (though the source was recently NBS'ed)
> but lrm/lum/drivers and such are looking to be issues.

There is no lum and lrm isn't an issue (even if it doesn't go to dkms, I 
don't think it can be considered a serious problem shipping -rt without 
those drivers).

> I'll let Alessio chime in but I'm opening this up to the wider kernel
> community for options/opinions.

Please do. We can't help if there is no communication from the person 
handling this. I appreciate that you are taking up the cause, but 
Alessio needs to take part.

> How has -zen dealt with this for instance?

Xen domU is built into our current kernel. I don't think there are any 
plans to incorporate a dom0 kernel for intrepid.

More information about the kernel-team mailing list