[yocto] how to organize my patches for multiple kernels and multiple target boards?

[Bruce Ashfield]

On 2016-03-02 10:41 AM, Robert P. J. Day wrote:
> Quoting Bruce Ashfield <bruce.ashfield at windriver.com>:
>
>> On 16-03-01 05:44 AM, Robert P. J. Day wrote:
>
>>>   also, once a .scc file is located, will the location of the listed
>>> .cfg and .patch/.diff files inside it start a whole new search process
>>> based on FILESEXTRAPATHS and FILESOVERRIDES?
>
>> The search path is created relative to the .scc file that is referencing
>> a patch, and across any directory that has a .scc file in the SRC_URI.
>> The .scc feature descriptions are self contained, hence "reaching
>> outside"
>> to a parent, or other directory structure isn't a good thing. Just list
>> things on the SRC_URI if that is required.
>
>    one more question, if i might, as i'm still unclear on what flexibility
> i have with finding .cfg or .patch files from a .scc file.
>
>    imagine i have a number of kernel .bbappend files and corresponding
> patch directories:
>
>    * linux-4.0.bbappend and linux-4.0/
>    * linux-4.1.bbappend and linux-4.1/
>    * linux-4.2.bbappend and linux-4.2/
>
> and so on, as well as wanting to refer to five machines, "m1" through
> "m5". consider the following possibility related specifically to
> kernel version 4.1:
>
>    linux-4.1/
>      rday.scc
>      1.patch
>      2.patch
>      3.patch
>      4.patch
>      m3/
>        4.patch
>
> so imagine my linux-4.1.bbappend file does SRC_URI += "rday.scc" --
> when i do a build for kernel 4.1, the search process should locate
> the rday.scc file in linux-4.1/ (as long as i have no other
> higher-priority FILESOVERRIDES that get in the way, of course).
>
>    now if rday.scc contains references to all four patches and i'm
> building for, say, machine "m1", it makes sense that all four
> of those patches directly under linux-4.1/ will be the ones
> included, correct?

Correct. Assuming rday.scc and the patch files are all within that
directory, it would be:

patch 1.patch
patch 2.patch
... etc.

And that would find the ones local to the .scc file.

>
>    but if, instead, i was building for machine "m3", as you can
> see, it would be nice if the FILESOVERRIDES feature would kick in
> and select the machine-specific patch "m3/4.patch. so all of the
> regular patches would be used, *unless* i was building for m3,
> at which point the patch m3/4.patch would override the "generic"
> 4.patch. (the same logic would apply to .cfg files, too, of course.)
>
>    is that what would happen? better yet, is that anything i
> should even be contemplating? it's not as if i need that feature
> right this instant, but it would be nice to know it's available
> just in case.

That doesn't happen. Since the searching for patches is not tied
to the fetcher searching and ordering directly.

You can switch on matchines within a .scc file, but that's not
really all that common.

>
>    even weirder, could i get away with something like this?
>
>    linux-4.1/
>      rday.scc
>      1.patch
>      2.patch
>      3.patch
>      4.patch
>      m3/
>        rday.scc
>        4.patch
>
> once again, my .bbappend file would "SRC_URI += rday.scc", and if
> i'm building for kernel 4.1, it should find the one directly under
> linux-4.1/, *unless* my target machine is "m3", at which point
> the file m3/rday.scc would take precedence, which would pick up
> the specific patch file m3/4.patch, but would use the higher-level
> generic patch files for all others.


Assuming the fetch found m3/rday.scc in the search paths first, it
would be the one selected.

But then the patch references would be relative to m3/, so you wouldn't
even find "patch 1.patch", etc.


The way this is typically configured if you aren't using a kernel-cache
structure is:

  linux-<foo>/
      machine-type1.scc
      machine-type2.scc
      machine-type3.scc
      common/
        1.patch
        2.patch
        3.patch
        4.patch
       type3/
        4.patch

And then you select the one that matches in your SRC_URI, or if the
.scc files have: "define KMACHINE type1", and you put them ALL on
the SRC_URI, the system will actually pick only the one that
matches the set $MACHINE.

 From there, that matching .scc file does all it's own includes of
patches and configuration blocks, etc.

Bruce

>
>    the first case i think has value and i'd like to know how to do
> it; the second case is admittedly weirder and i'm not sure i
> want to defend even *trying* to do it, but i figured i'd ask.
>
> rday
>
>