[linux-yocto] Linux-yocto-custom and meta-data
bruce.ashfield at windriver.com
Mon Oct 15 16:42:47 PDT 2012
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).
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
> 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.
More information about the linux-yocto