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
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
