[poky] PREEMPT_RT support

[Bruce Ashfield]

On Mon, Dec 6, 2010 at 10:35 PM, Darren Hart <dvhart at linux.intel.com> wrote:
> On 12/06/2010 05:00 PM, Bruce Ashfield wrote:
>>
>> On 10-12-06 6:06 PM, Darren Hart wrote:
>>>
>>> I'm looking at how to best support PREEMPT_RT. We have a few things in
>>> the works which prevent the ideal scenario (which is just a new recipe
>>> using the preempt_rt branch in linux-yocto).
>>>
>>> 2.6.34 never had an -rt patch. The WR folks created one that builds and
>>> is undergoing review from tglx - but that doesn't appear to be near the
>>> top of his stack. 2.6.37 is still pending an -rt patch, also blocked on
>>> -tglx.
>>
>> We'll be doing one at WR eventually, so it will exist in
>> one form or another for version > 2.6.34.
>
> My wording above wasn't quite right. tglx will be releasing a 2.6.37 -rt
> tree, that is committed. We're just waiting for it to emerge. There are a
> handful of reworks that will begin with 2.6.37 and may delay things some,
> but it will emerge.

Right, I recall hearing that at the plumbers conference as well.
I'd like to 'abstract' my statement such that, we can always consider
doing ports if for some reason the upstream tree doesn't move
or match the cadence. We've had to do a 2.6.27 and .34 custom -rt
inside Wind River for just this reason.

>
>>
>>>
>>> I'm thinking of creating a meta-rt layer which would provide a latest
>>> -rt kernel and the rt-tests suite along with a non-graphical image
>>> definition that facilitates latency detection and rt performance
>>> measurement. poky-image-rt-test or something along those lines.
>>>
>>> Any objection to this approach? As we will eventually move these recipes
>>> into the core poky recipes, I'd suggest we put this in an
>>> "experimental/meta_rt" git repository.
>>
>> I'm worrying about this muddying the water with respect to the
>> -rt branches in the linux-yocto repositories. In particular if
>> we go *backward* from the 2.6.34 variant that we already have
>> (remember, that -rt kernel has been heavily abused for 9
>> months now and is just as stable (probably more so for
>> non-x86) as anything else you'll find).
>>
>> Why can't we continue to consolidate these into fewer kernels
>> and recipes ? We can't share fixes and BSPs easily if everything
>> is kept separate. We can obviously pair the tests/utilities along
>> with the linux-yocto -rt branches, so I'd prefer that approach
>> and continue to work on improving the base that we already
>> have.
>
> Hrm. Perhaps my perception of the 2.6.34 kernel is flawed. I wasn't aware
> that this particular version of the patch had seen so much runtime. If that

It has been used a lot, even deployed in products, the stabilization
was long running on about 15 or 20 targets. I'm confident that it has
seen enough burn time

> is the case, instead of an rt-layer, I'll just prepare an rt kernel recipe
> (as we discussed) using the linux-yocto kernel and add rt-tests. Both to the
> core poky meta dir.

This works, and we can update the -rt branches in the 2.6.34 based
kernel to suit.

Cheers,

Bruce

>
> I think it would still make sense to have a linux-rt_tip.bb, which builds
> from linux-2.6-tip.git/rt/head as a sort of developers kernel. Perhaps this
> would work well with the other dev recipes you have simmering?
>
>
> --
> Darren Hart
> Yocto Linux Kernel
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"