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

[Bruce Ashfield]

On 12-10-15 7:47 PM, Darren Hart wrote:
>
>
> 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.

Yep. Both are ok, and you don't even need to call it -standard.scc,
since the file name isn't searched, only the contents for the right
ktype/kmachine that best matches the machine+ktype passed down from
the build system.

>
>> 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 ;-).

ok. I'll have a whack at it in the morning if I don't see a report
of success .. or failure (I hope not :)

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

Agreed. Sounds like the best option.

Cheers,

Bruce

>