On Thu, Dec 7, 2017 at 8:15 AM, Mike Crowe <[email protected]> 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. > > 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. > Thanks. > > Mike. > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
