[OE-core] [PATCH] default-distrovars: set default KERNEL_IMAGETYPE(S)

Andre McCurdy armccurdy at gmail.com
Thu Mar 29 23:58:32 UTC 2018


On Thu, Mar 29, 2018 at 4:55 PM, Cal Sullivan
<california.l.sullivan at intel.com> wrote:
> On 03/29/2018 04:36 PM, Andre McCurdy wrote:
>> On Thu, Mar 29, 2018 at 4:19 PM, California Sullivan
>> <california.l.sullivan at intel.com> wrote:
>>>
>>> With the change from assuming kernels will be named "vmlinuz"
>>> everywhere, to instead using KERNEL_IMAGETYPE, we require that
>>> KERNEL_IMAGETYPE is set to something. Instead of setting the default in
>>> multiple individual files, set it in default-distrovars.inc.
>>>
>>> Also set KERNEL_IMAGETYPES, as we will eventually be switching away from
>>> KERNEL_IMAGETYPE.
>>>
>>> Signed-off-by: California Sullivan <california.l.sullivan at intel.com>
>>> +
>>> +KERNEL_IMAGETYPE ??= "bzImage"
>>
>> Isn't bzImage x86 specific? Setting it as the default also disagrees
>> with meta/conf/documentation.conf:
>>
>>    KERNEL_IMAGETYPE[doc] = "The type of kernel to build for a device,
>> usually set by the machine configuration files and defaults to
>> 'zImage'."
>>
>> It might be nice to have an arch specific default (e.g. bzImage for
>> x86, vmlinux for MIPS and zImage for everything else?).
>
>
> Doing so would require a nasty setVar python block due to overrides taking
> priority.
>
> E.g.,
> KERNEL_IMAGETYPE_x86 ??= "test1"
> KERNEL_IMAGETYPE = "test2"
> results in KERNEL_IMAGETYPE getting "test1".
>
> That or accept the difficulty of overriding it afterwards.

How about:

ARCHDEFAULT_KERNEL_IMAGETYPE = "zImage"
ARCHDEFAULT_KERNEL_IMAGETYPE_x86 = "bzImage"

KERNEL_IMAGETYPE ?= "${ARCHDEFAULT_KERNEL_IMAGETYPE}"

> This patch is primarily in order to set /any/ default globally so that
> getVar calls on it don't break parsing.
> Its still customary to set the variable in machine confs as well.
>
> I can send a v2 that sets the default to zImage instead. That way it matches
> the docs, though I don't know how accurate they were previously.
>
> Thanks,
> Cal
>



More information about the Openembedded-core mailing list