On Friday 08 December 2017 at 14:24:17 -0800, Andre McCurdy wrote: > On Fri, Dec 8, 2017 at 1:34 PM, Khem Raj <[email protected]> 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.
Well, anyone who also didn't notice the change in units probably hasn't noticed the breakage yet either. :-) But, I mostly agree. It's clear the size check feature is used, but it's quite possible that it isn't used in combination with multiple image type support. So, I think something along the same lines as the patch I submitted[1] is worth applying, even if in the longer term something better might be desirable. Mike. [1] https://patchwork.openembedded.org/patch/146518/ http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145402.html -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
