[OE-core] kernel.bbclass do_sizecheck behaviour changes

[Andrea Adami]

On Fri, Dec 8, 2017 at 11:24 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> On Fri, Dec 8, 2017 at 1:34 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>
>>> 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.
>>
>> I was hoping that we are talking about deployed kernels here compressed
>> sizes can vary widely too
>>
>> So may be we can have a hook to define which image types should be monitored
>> and what the limits are for individual type
>
> We could do a lot of things and add a lot of complexity. However based
> on the fact that the simplest test has been broken for some time and
> no-one noticed, the evidence is that the kernel image size check isn't
> a widely used feature (and the kernel image size check with multiple
> kernel image types even less so, if at all) and so probably shouldn't
> be the focus of our efforts.
> --


Hi,

we use do_sizecheck since oe-classic and noticed the change thus
patched our kernel recipe back in 2014.
So no, it has not been broken for long in the actively maintained layers ;).
See
http://cgit.openembedded.org/meta-handheld/commit/recipes-kernel/linux?id=e51a0c84c65651a646ac701a411f724c0ed583a6

We do build only one type (zImage) so is preferable to have the test
fail if size exceeds, not just a warning.

Besides, I am annoyed by the related change for the creation of
different image types in case of errors: I do build ubifs images and
if the size exceeds the eraseblocks of the device and mkufbifs fails
then the other images types are not deployed (tar.gz, ext3, ...).
I plan to fix this somehow, it wasn't like that originally.

Cheers
Andrea


> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core