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

[Bruce Ashfield]

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

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.

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

Cheers,

Bruce

>