<div><br><div class="gmail_quote"><div dir="auto">On Thu, Dec 7, 2017 at 11:44 AM Andre McCurdy <<a href="mailto:armccurdy@gmail.com">armccurdy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Dec 7, 2017 at 11:20 AM, Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>> wrote:<br>
> On Thu, Dec 7, 2017 at 8:15 AM, Mike Crowe <<a href="mailto:mac@mcrowe.com" target="_blank">mac@mcrowe.com</a>> wrote:<br>
>> I discovered today that our kernel size check has been ineffective since we<br>
>> took 7384d2831c713ac5999aca83c312154dc15cec56 from 2014 which changed the<br>
>> units for KERNEL_IMAGE_MAXSIZE from bytes to kilobytes.<br>
>><br>
>> However whilst fixing that, I also noticed that<br>
>> 849b67b2e4820564b5e5c9bd4bb293c44351c5f3 in 2016 changed the consequences<br>
>> of exceeding the size from being fatal to merely a warning.<br>
>><br>
>> This second change in behaviour wasn't described in the commit message, so<br>
>> I'm not sure whether it was intentional. I can believe that when generating<br>
>> multiple kernel image types it may not be essential that they all fit, but<br>
>> I don't really know what the use case for the feature is.<br>
>><br>
>> I could fix this by adding to kernel.bbclass something like:<br>
>><br>
>> KERNEL_IMAGE_MAXSIZE_CONSEQUENCE ?= "warn"<br>
>><br>
>> and then using it when delivering the bad news so that recipes can override<br>
>> it if they wish.<br>
>><br>
>> Alternatively, I could treat the error as being fatal if none of the kernel<br>
>> images fit within the required size. This would degenerate to the old<br>
>> behaviour automatically if KERNEL_IMAGETYPES contains only one entry.<br>
<br>
That sounds like a good solution.<br>
<br>
>> Does one of these solutions appeal, or is there another even better<br>
>> solution?<br>
><br>
> I think default should be a warning with a possibility to be turned<br>
> into an error<br>
> if user wishes too. I think if you are generating multiple kernel types then you<br>
> will use all of them somewhere, so I would say if the size of one of<br>
> them excedes<br>
> the set limit them break the build.<br>
<br>
The size limit for an uncompressed kernel vs a compressed kernel is<br>
going to be quite different, so defining one size limit and applying<br>
it to all images doesn't seem logical.</blockquote><div dir="auto"><br></div><div dir="auto">I was hoping that we are talking about deployed kernels here compressed sizes can vary widely too</div><div dir="auto"><br></div><div dir="auto">So may be we can have a hook to define which image types should be monitored and what the limits are for individual type</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></div></div>