[OE-core] kernel.bbclass do_sizecheck behaviour changes

[Andre McCurdy]

On Thu, Dec 7, 2017 at 11:20 AM, Khem Raj <raj.khem at gmail.com> wrote:
> On Thu, Dec 7, 2017 at 8:15 AM, Mike Crowe <mac at mcrowe.com> wrote:
>> I discovered today that our kernel size check has been ineffective since we
>> took 7384d2831c713ac5999aca83c312154dc15cec56 from 2014 which changed the
>> units for KERNEL_IMAGE_MAXSIZE from bytes to kilobytes.
>>
>> However whilst fixing that, I also noticed that
>> 849b67b2e4820564b5e5c9bd4bb293c44351c5f3 in 2016 changed the consequences
>> of exceeding the size from being fatal to merely a warning.
>>
>> This second change in behaviour wasn't described in the commit message, so
>> I'm not sure whether it was intentional. I can believe that when generating
>> multiple kernel image types it may not be essential that they all fit, but
>> I don't really know what the use case for the feature is.
>>
>> I could fix this by adding to kernel.bbclass something like:
>>
>>  KERNEL_IMAGE_MAXSIZE_CONSEQUENCE ?= "warn"
>>
>> and then using it when delivering the bad news so that recipes can override
>> it if they wish.
>>
>> Alternatively, I could treat the error as being fatal if none of the kernel
>> images fit within the required size. This would degenerate to the old
>> behaviour automatically if KERNEL_IMAGETYPES contains only one entry.

That sounds like a good solution.

>> Does one of these solutions appeal, or is there another even better
>> solution?
>
> I think default should be a warning with a possibility to be turned
> into an error
> if user wishes too. I think if you are generating multiple kernel types then you
> will use all of them somewhere, so I would say if the size of one of
> them excedes
> the set limit them break the build.

The size limit for an uncompressed kernel vs a compressed kernel is
going to be quite different, so defining one size limit and applying
it to all images doesn't seem logical.