Re: how to organize my patches for multiple kernels and multiple target boards?

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 2016-02-29 6:19 PM, Robert P. J. Day wrote:
>    (i posted a much lengthier version of this on oe-core recently, but i
> want
> to cut it down and ask specific questions to clarify what i *think* is
> going
> on.)
>
>    i want to pull in an existing layer with recipes for linux-4.0.bb and
> linux-4.1.bb, and extend them with .bbappend files, to support two
> closely-related
> machines i'm defining -- call them "mach1" and "mach2". AFAICT, my
> patches will
> fall somewhere in a 3x3 matrix of possibilities:
>
>    * 3 possibilities of applying against mach1, mach2 or both
>    * 3 possibilities of applying against linux-4.0, linux-4.1 or both
>
> so there's my 3x3 matrix.
>
>    the obvious kernel recipe directory structure would be:
>
>    linux/
>      linux-4.0.bbappend
>      linux-4.1.bbappend
>      linux-4.0/            [4.0-specific patches]
>      linux-4.1/            [4.1-specific patches]
>      linux/                [patches that apply to both]
>
> which suggests that both my .bbappend files would have to contain the line:
>
>    FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:${THISDIR}/${BPN}"
>
> so the SRC_URI search path for linux-4.0.bbappend entries would be
> prepended with:
>
>    * linux-4.0/        [4.0-specific patches]
>    * linux/            [patches that apply to both]
>
> and similarly for linux.4.1.bbappend. how am i doing so far? this would
> mean that, for each recipe, the more specific directory would be searched
> before the general directory. but wait ... there's more.
>
>    now i want to further categorize patches based on exclusive to mach1,
> exclusive to mach2, or applicable to both, and since the machine name is
> one of the entries in FILESOVERRIDES, i can extend the directory structure
> as:
>
>    linux-4.0/
>      mach1/
>      mach2/
>    linux-4.1/
>      mach1/
>      mach2/
>    linux/
>      mach1/
>      mach2/
>
> and there's my 3x3 matrix of patches, correct? and here's where it gets
> unclear.
>
>    i really don't want to have to number all my patches with prefixes like
> 0001-, 0002- and so on, so what is the ordering of processing for .scc,
> .cfg and .patch/.diff files? rather than just lump all the patches into
> a single .scc file, i want to refine the patches across multiple .scc
> files. is there an imposed order on SRC_URI entries, .scc files and so
> on? that's probably all i need to finish this off.

No matter what you method you choose, ordering is as they appear in the
SRC_URI (and normal variable evaluation rules apply)/.

Having maintained more than a few kernel's, my warning is that depending
on your patches, the advantages of mixing version independent patches
with version specific (and board ones) can end up causing a lot of extra
work and maintenance pain. It of course all comes down to what parts of
the kernel they touch, but assuming a normal set of patches you'll find
that you end up tweaking things for order, and then moving patches into
version/board specific places, etc. In particular if you update the base
kernel's to have things like -stable, or other patches that touch lots
of code.

Outside of the kernel version handling (see my warning above), managing
the patches by the SRC_URI works, as would .scc files. Since the entire
point of .scc files is to define a board entry point (the top level .scc
file), and then have it include common patches, configs, etc, all from
that file.

There is another alternative to that management of patches/configs/boards,
and you can create a kernel-cache directory and refer to it on the
SRC_URI. In master, that's how all the boards and patches are managed.

Cheers,

Bruce



>
> rday
>
>
>