[OE-core] kernel.bbclass do_sizecheck behaviour changes

[Khem Raj]

On Thu, Dec 7, 2017 at 11:44 AM Andre McCurdy <armccurdy at gmail.com> wrote:

> 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.


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

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20171208/0d516f78/attachment-0002.html>