[linux-yocto] Linux-yocto-custom and meta-data

[Darren Hart]

On 10/15/2012 04:42 PM, Bruce Ashfield wrote:
> On 12-10-15 7:26 PM, Darren Hart wrote:
>> I've got a customer that insists on using their own kernel version, but
>> doesn't want to keep their config in recipe-space. I already have them
>> using linux-yocto-custom with a linux 3.5 based git repository. Seems to
>> me the best way to address this would be for them to create a meta
>> directory in their master branch which contains their BSP definition. Is
>> it as simple as the following?
>>
>>    $ tree meta
>>
>>    meta/cfg/kernel-cache/bsp/common-pc
>>    └── cfg
>>        └── kernel-cache
>>            └── bsp
>>                └── mybsp
>>                    ├── mybsp.cfg
>>                    └── mybsp.scc
>>
>> Where mybsp.scc is:
>>
>>    define KMACHINE mybsp
>>    define KARCH i386
>>    kconf hardware mybsp.cfg
>>
>> This doesn't define any kernel types, would we need to do that, or can
>> the tools deal with that?
> 
> The tools want to search by kmachine + ktype. In theory they can just
> search on one and get the best match, so taking the default ktype of
> standard *should* work (and not specifying it in the .scc, but it
> should still be passed to the tools).


So if I specify KTYPE=standard and MACHINE=mybsp, then I should be able
to get away with:


   meta
   └── cfg
       └── kernel-cache
           └── bsp
               └── mybsp
                   ├── mybsp.cfg
                   └── mybsp-standard.scc

Note the mybsp-standard.scc name, and the lack of a
ktype/standard/standard.scc.

> If storing that structure under 'meta' doesn't work, it's something
> I can get working. If you don't get around to testing it, I will
> in the morning. It's not a use case we had covered yet, so I wouldn't
> consider it a defect .. but it is a good use case that should be
> supported.

OK, I won't be getting to it tonight I don't think, but let's report
our progress here to keep in sync. This is rather time sensitive (for
me anyway ;-).

> 
>>
>> Obviously it would be more ideal to use the linux-yocto repository
>> itself with common base kernel version and create policy and hardware
>> fragments, etc. But given these constraints, is this about right?
> 
> It's a step in the right direction, bonus points if you can at least
> convince them to share the policy from linux-yocto  by taking the
> yocto-kernel-cache as a baseline, that way it'll be at least similar
> to the linux-yocto tree.

Unfortunately that won't be happening initially. mybsp.cfg is going to
be a complete defconfig. This is more political than technical,
unfortunately.

However, if we can get a yocto meta tree in their sources, that will
make the ultimate transition all that much easier in the future.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel