[linux-yocto] Linux-yocto-custom and meta-data
bruce.ashfield at windriver.com
Mon Oct 15 16:56:06 PDT 2012
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
>>> └── 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:
> └── cfg
> └── kernel-cache
> └── bsp
> └── mybsp
> ├── mybsp.cfg
> └── mybsp-standard.scc
> Note the mybsp-standard.scc name, and the lack of a
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
> 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,
> 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.
More information about the linux-yocto