From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Cc: Saul Wold <saul.wold@intel.com>
Subject: Re: [RFC 2/2] image_types: add IMAGE_ROOTFS_EXTRA_SPACE
Date: Thu, 26 May 2011 13:58:44 -0700 [thread overview]
Message-ID: <4DDEBF04.4080106@linux.intel.com> (raw)
In-Reply-To: <4DDE9A66.6070900@intel.com>
On 05/26/2011 11:22 AM, Saul Wold wrote:
> On 05/26/2011 11:04 AM, Joshua Lock wrote:
>> On Mon, 2011-05-23 at 23:38 -0700, Saul Wold wrote:
>>> [YOCTO #886]
>>>
>>> This address 2 needs after the IMAGE_ROOTFS_SIZE is cleaned up, by
>>> removing some of the _ext2/3 overrides it allows for a cleaner override
>>> using IMAGE_ROOTFS_SIZE to create a large rootfs, or by setting the
>>> IMAGE_ROOTFS_EXTRA_SPACE, will allow for extra space allocated in Kilobytes
>>> above the base size (determined by du of the rootfs * IMAGE_OVERHEAD_FACTOR,
>>> default of 1.3).
>>>
>>> Signed-off-by: Saul Wold<sgw@linux.intel.com>
>>> ---
>>> meta/classes/image_types.bbclass | 2 +-
>>> meta/conf/bitbake.conf | 4 ++++
>>> 2 files changed, 5 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
>>> index 69f859e..601a5fb 100644
>>> --- a/meta/classes/image_types.bbclass
>>> +++ b/meta/classes/image_types.bbclass
>>> @@ -13,7 +13,7 @@ def get_imagecmds(d):
>>>
>>> runimagecmd () {
>>> # Image generation code for image type ${type}
>>> - ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{size = $1 * ${IMAGE_OVERHEAD_FACTOR}; print (size> ${IMAGE_ROOTFS_SIZE} ? size : ${IMAGE_ROOTFS_SIZE}) }'`
>>> + ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{size = $1 * ${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_EXTRA_SPACE}; print (size> ${IMAGE_ROOTFS_SIZE} ? size : ${IMAGE_ROOTFS_SIZE}) }'`
>>> ${cmd}
>>> cd ${DEPLOY_DIR_IMAGE}/
>>> rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>> index a0af672..fa3618c 100644
>>> --- a/meta/conf/bitbake.conf
>>> +++ b/meta/conf/bitbake.conf
>>> @@ -350,6 +350,10 @@ IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
>>> # This option allows for a precentage overage of the actaul image size rather than a
contextual fix while you're at it:
s/precentage/percentage/
s/actaul/actual/
>>> # fixed extra space
>>> IMAGE_OVERHEAD_FACTOR ?= 1.3
>>> +# This option allow for adding addition space in K above and beyond what the
>>> +# IMAGE_OVERHEAD_FACTOR might add. To set a fixed size then overrideing IMAGE_ROOTFS_SIZE
>>> +# with the max size one wants should do the trick
>>> +IMAGE_OVERHEAD_EXTRA_SPACE = "0"
>>
>> This appears to be a different variable to the IMAGE_ROOTFS_EXTRA_SPACE
>> used in the command above? Also, you've done a hard assignment here.
>> Shouldn't it be a soft (?=) assignment?
>>
> Yes, I fixed the OVERHEAD vs ROOTFS already, noticed that during post
> RFC testing. I did not see the soft (?=) problem, but agree it needs to
> be fixed.
>
Hrm, I didn't realize there were two variables. If
IMAGE_ROOTFS_EXTRA_SPACE is used to ensure the user has some space for
their data, what then is the idea driving IMAGE_OVERHEAD_FACTOR?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
prev parent reply other threads:[~2011-05-26 21:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 6:38 [RFC 0/2] IMAGE_ROOTFS_SIZE Cleanup Saul Wold
2011-05-24 6:38 ` [RFC 1/2] " Saul Wold
2011-05-26 18:04 ` Joshua Lock
2011-05-26 18:28 ` Saul Wold
2011-05-26 19:54 ` Joshua Lock
2011-05-26 20:55 ` Darren Hart
2011-05-26 21:01 ` Joshua Lock
2011-05-26 21:03 ` Darren Hart
2011-05-26 21:13 ` Joshua Lock
2011-05-26 21:15 ` Saul Wold
2011-05-26 21:31 ` Joshua Lock
2011-05-26 21:14 ` Paul Eggleton
2011-05-27 4:07 ` Darren Hart
2011-05-27 4:29 ` Saul Wold
2011-05-27 5:22 ` Darren Hart
2011-06-02 1:46 ` Tom Rini
2011-05-24 6:38 ` [RFC 2/2] image_types: add IMAGE_ROOTFS_EXTRA_SPACE Saul Wold
2011-05-26 18:04 ` Joshua Lock
2011-05-26 18:22 ` Saul Wold
2011-05-26 20:58 ` Darren Hart [this message]
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=4DDEBF04.4080106@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=saul.wold@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox