From: Darren Hart <dvhart@linux.intel.com>
To: Saul Wold <sgw@linux.intel.com>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC 1/2] IMAGE_ROOTFS_SIZE Cleanup
Date: Thu, 26 May 2011 22:22:04 -0700 [thread overview]
Message-ID: <4DDF34FC.3060100@linux.intel.com> (raw)
In-Reply-To: <4DDF2893.7090306@linux.intel.com>
On 05/26/2011 09:29 PM, Saul Wold wrote:
> On 05/26/2011 09:07 PM, Darren Hart wrote:
>>
>>
>> On 05/26/2011 02:14 PM, Paul Eggleton wrote:
>>> On Thursday 26 May 2011 22:03:02 Darren Hart wrote:
>>>> Yeah, this wasn't clear to me either. And my question in 2/2 still
>>>> stands - what is the goal of the overhead factor?
>>>
>>> I think the thinking was that the more software you have installed to begin
>>> with the more user data you're likely to need to store. Personally I think it
>>> would be simpler if we just set some additional overhead as an absolute value
>>
>> I had the same thought, so "seconded".
>>
> It used to be that way and failed in unpredictable ways, what would work
> for one image would be way over kill for another or be too little, so
> the overhead factor works better.
>
Seems to me this is just slightly more complicated, but every bit as
likely to fail in unexpected ways in the future. Perhaps the simplest,
most robust, and most explicit way to address this would be to set the
IMAGE_ROOTFS_EXTRA_SPACE in each IMAGE file, just as we set the base size?
This still ensures you get at least IMAGE_ROOTFS_EXTRA_SPACE freespace
since the base size will expand to be at least the size the image requires.
My final 0.02 USD on the matter.
> If you want a known amount of space then you can use the
> IMAGE_ROOTFS_EXTRA_SPACE.
>
> Sau!
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2011-05-27 5:25 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 [this message]
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
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=4DDF34FC.3060100@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
--cc=sgw@linux.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