[poky] kernel type selection

[Bruce Ashfield]

On Mon, Dec 20, 2010 at 4:19 PM, Khem Raj <raj.khem at gmail.com> wrote:
> On (20/12/10 10:15), Darren Hart wrote:
>> On 12/19/2010 09:08 PM, Bruce Ashfield wrote:
>> >On Tue, Dec 14, 2010 at 3:59 PM, Darren Hart<dvhart at linux.intel.com>  wrote:
>> >>In developing new kernel recipes, I've run across some difficulty in
>> >>determining the ideal way to select one kernel recipe over another. The
>> >>machine configs specify the preferred provider. For the Linaro layer, I
>> >>setup new machine configs which specified the linux-linaro as the preferred
>> >>kernel.
>> >
>> >kicking some life into this thread, I scanned it earlier, but was preoccupied
>> >with getting .37 out and the SRCREV issues until now.
>> >
>> >I've had similar issues to this when working on the -stable versus -dev
>> >yocto trees. Since the preferred kernel is in the machine files, switching
>> >between -stable and -dev requires an update to the conf files, and if a
>> >machine prefers one kernel type, manually building one forces a wait
>> >through the preferred kernel first (not always what I wanted).
>> >
>> >>
>> >>As I'm working with preempt_rt, I'm running into this again. I could create
>> >>more machine configs, but this approach won't scale well (having to create a
>> >>copy of all the supported machine configs just to change the preferred
>> >>kernel). I could set LINUX_KERNEL_TYPE="preempt_rt" in my local.conf, but
>> >>that would reuse all the settings in the existing recipes (like
>> >>COMPATIBLE_MACHINES), all of which don't necessary apply to the new kernel
>> >>type.
>> >
>> >LINUX_KERNEL_TYPE_<machine>="preempt_rt"
>> >
>> >Would be the way to put in your local conf and have it only impact
>> >a single machine. But now that I think of it, I haven't tried that in
>> >the local.conf, so someone can correct me if variable overrides don't
>> >work there.
>> >
>> >>
>> >>I've considered looking for a way to specify the kernel type in the new
>> >>image definitions (ie poky-image-rt) and creating new recipes for each
>> >>kernel type. I like the idea of one recipe per kernel type as this makes
>> >>things more explicit and avoids contamination between the various kernel
>> >>types. This approach however seems to be at odds with the Poky way of doing
>> >>this which, as I understand it, would be to specify the provider in the
>> >>machine config and any modifiers (like type) in the local.conf.
>> >
>> >I'd agree that cloning and adding more machine configs just to
>> >change kernel types will rapidly increase the count, and if we don't
>> >setup includes appropriately, could lead to errors.
>> >
>> >>
>> >>Can we get a discussion started here to determine some best practices?
>> >
>> >I'm not sure about best practices, but I had planned to tackle
>> >this in similar ways to what we've been using layers at Wind River to solve this
>> >for the past several years.
>> >
>> >a) have a single recipe that switches the kernel type based on a
>> >     variable being set. That's pretty much what you have above, but
>> >     as we've discussed in the past, mux'ing through a single recipe
>> >     that behaves differently based on configuration isn't always in line
>> >     with other recipes I've seen.
>> >b) make a -rt layer, that when included overrides the preferred kernel to
>> >     preempt_rt. This is consistent with other layering schemes that trigger
>> >     behaviour when you include a particular layer. The addition of the layer
>> >     is the indication that you want a specific configuration to happen.
>> >c) put the preferred kernel in an include file, and make that include
>> >     conditional on something that is set in the local environment. This is
>> >     pretty much what we'd do with the kernel type being set, so there's
>> >     really not much different here.
>>
>> Taking a step back and thinking about this from a user's perspective.
>>
>> a.1) Edit local.conf
>>       LINUX_KERNEL_TYPE_atom-pc="preempt_rt"
>>    A tad arcane, but any habitual bitbake user shouldn't complain too
>>    much. This assumes the only thing that needs to change for PREEMPT_RT
>>    is the kernel type, when, in fact, things like COMPATIBLE_MACHINES
>>    should also change or the user is likely to run into strange errors
>>    if they try to build on an untested machine.
>>
>> a.2) Edit local.conf
>>    PREFERRED_PROVIDER_vitual/kernel_atom-pc-"linux-yocto-rt"
>>    Other than being slightly more arcane, this addresses the issues of
>>    the kernel type solution.
>>
>> b) Edit bblayers.conf
>>    /path/to/poky/meta-rt
>>    Fairly intuitive user-action. The machine.conf appends should likely
>>    follow a.2.
>>
>> c) pretty much the same as a)
>>
>> I still find the tying of PREEMPT_RT to the machine to be
>> non-intuitive, and the setting in the build conf to be too broad. It
>> applies to every image built for those machines. This makes adding rt
>> specific images a bit irregular since you could build them without
>> a preempt_rt kernel (or perhaps an RDEPENDS would prevent build) and
>> if the other settings are in place, selecting a non-rt image will result
>> in that image with a PREEMPT_RT kernel.
>>
>> In my opinion, the ideal user experience would be:
>>
>> $ bitbake poky-image-rt
>>
>> Which then reports:
>>
>> Error: $MACHINE does not have linux-yocto-rt support.
>>
>> or it successfully builds.
>>
>> The problem with this approach as I understand it, is the image
>> recipe is too far along in the bitbake process to be able to
>> influence the
>> kernel selected for the image.
>>
>> So we can either opt for b) which I see as the least of all evils, or we
>> can look into ways to enhance image recipes to be able to influence
>> PREFERRED_PROVIDER_virtual/kernel.
>>
>> Thoughts?
>
> How about making preemt_rt part of MACHINE_FEATURE or DISTRO_FEATURE
> and when chosen it uses the right kernel.

Hi Khem,

This would work as well, but takes us to the same place we are with
other options (and that's the sticky point), in that we need dedicated
machine conf files to specify the different kernel type.

We've got a variable that is specific to the yocto kernel recipes that
serves the purpose for now, and triggering it by the inclusion of a
meta-rt layer makes the selection the cleanest we've come up with
so far.

Again, this is a good idea, and if the recipe specific variable were to
be changed in the future, we could definitely use this to indicate the
kernel type to the recipes and make a decision based these variables.

And you never know, we may decide on some combination of all
the options! Thanks for adding more to the conversation.

Cheers,

Bruce

>
>>
>> --
>> 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"