On Thu, Dec 7, 2017 at 11:44 AM Andre McCurdy <armccu...@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 11:20 AM, Khem Raj <raj.k...@gmail.com> wrote: > > On Thu, Dec 7, 2017 at 8:15 AM, Mike Crowe <m...@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 > >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core