[poky] Minimal images: kernel config

[Tom Rini]

On 02/18/2011 11:52 AM, Mark Hatle wrote:
> On 2/18/11 12:25 PM, Richard Purdie wrote:
>> On Fri, 2011-02-18 at 09:52 -0800, Darren Hart wrote:
>>> I've been getting more and more questions regarding flash footprint,
>>> memory footprint, and boot time. All of these fall under the "minimal
>>> image" heading in my head.
>>>
>>> Currently, poky-image-minimal is a simple subset of poky-image-sato. It
>>> uses busybox, but is still dynamically linked and uses the same
>>> somewhat-generic kernel build. By somewhat-generic I mean we have named
>>> features that often cover more drivers than are stricly necessary for a
>>> given board (usb-net comes to mind). I'd like to see minimal become a
>>> truly minimal image from both the userspace and kernel side point of view.
>>>
>>> Here's my take on this. From userspace this means uclibc and a staticly
>>> linked busybox. From the kernel this means a static build (no modules)
>>> with nothing more than is required for the board's built-in peripherals
>>> to function, with the possible exception of something like usb-storage.
>>> I'd like to see a<  10M flash size and a<8M memory footprint.
>>>
>>> Thoughts on this direction?
>>
>> That sounds more like a "micro" rather than the current minimal. Minimal
>> is designed to be extended by the user, what you describe above is a lot
>> harder to extend.
>>
>> So my take is that minimal is ok as it is stands from the dynamic linked
>> busybox perspective and static linking doesn't buy you what you might
>> expect it to. mklibs will probably have just as much effect.
>>
>> For kernel modules, I suspect even for a micro, you still want them
>> since you can then start booting the kernel faster and only have what
>> you need in memory (say USB peripherals).
>>
>> I'm not against a micro type target but its smaller that what we've been
>> aiming for an introduces a new element into the Yocto test matrix.
>>
>> Having said all that, I expect there are ways to reduce minimal further
>> than it is today as its not something anyone has looked hard at so
>> far...
>
> The keys to reducing minimal further is eglibc configurability -- which we do
> not yet have implemented

While not yet being used heavily, this does exist in OE today thanks to 
Khem.  Perhaps this would be a good candidate for oe-core?

-- 
Tom Rini
Mentor Graphics Corporation