All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre McCurdy <armccurdy@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Mike Crowe <mac@mcrowe.com>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: kernel.bbclass do_sizecheck behaviour changes
Date: Fri, 8 Dec 2017 14:24:17 -0800	[thread overview]
Message-ID: <CAJ86T=XLobz3tiBOf+JqAt3JBV=o4HqUVBJwkjY0VR9LCDWNyQ@mail.gmail.com> (raw)
In-Reply-To: <CAMKF1srhviBz5_Y9Gsn=Db2y9wCJ8HN96+FjBci+XA3m1R-Pwg@mail.gmail.com>

On Fri, Dec 8, 2017 at 1:34 PM, Khem Raj <raj.khem@gmail.com> 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.


  reply	other threads:[~2017-12-08 22:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07 16:15 kernel.bbclass do_sizecheck behaviour changes Mike Crowe
2017-12-07 19:20 ` Khem Raj
2017-12-07 19:44   ` Andre McCurdy
2017-12-08 12:21     ` Mike Crowe
2017-12-08 21:34     ` Khem Raj
2017-12-08 22:24       ` Andre McCurdy [this message]
2017-12-11  9:49         ` Andrea Adami
2017-12-11 10:00         ` Mike Crowe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ86T=XLobz3tiBOf+JqAt3JBV=o4HqUVBJwkjY0VR9LCDWNyQ@mail.gmail.com' \
    --to=armccurdy@gmail.com \
    --cc=mac@mcrowe.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.