Minimal images: kernel config

Minimal images: kernel config

[Darren Hart]

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?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Minimal images: kernel config

[Richard Purdie]

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...

Cheers,

Richard

Re: Minimal images: kernel config

[Mark Hatle]

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, and use of mklibs.  Shared memory will likely be both
smaller disk and memory footprint then static binaries in this configuration.
(If not, it will be very close...)

The size of the kernel and modules is also a factor -- but as Richard mentioned,
it's fairly typical to have a lightly configured kernel as the boot kernel and
then load a lot of modules once the system comes alive.

My goal for a busybox / glibc based system is around 8 MB of disk usage... This
should be easily achievable when eglibc is able to be configured, mklibs is run
and a reasonable set of modules is available.

--Mark

> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

Re: Minimal images: kernel config

[Darren Hart]

On 02/18/2011 10: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, and use of mklibs.  Shared memory will likely be both
> smaller disk and memory footprint then static binaries in this configuration.
> (If not, it will be very close...)
>
> The size of the kernel and modules is also a factor -- but as Richard mentioned,
> it's fairly typical to have a lightly configured kernel as the boot kernel and
> then load a lot of modules once the system comes alive.
>
> My goal for a busybox / glibc based system is around 8 MB of disk usage... This
> should be easily achievable when eglibc is able to be configured, mklibs is run
> and a reasonable set of modules is available.

In that case, perhaps we can accomplish my goals without a new type of 
image (micro as rp called it - which is a heckuvalot bigger than a yocto 
I should add ;-).

Something to add to the "to investigate" list.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Minimal images: kernel config

[Bruce Ashfield]

On 11-02-18 12:52 PM, 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.

 From the kernel angle, I have a profile/solution for this
lurking in the 2.6.34 kernel, and one that we've been updating
for the 2.6.37 kernel.

There's a kernel feature called "small", that when overlayed
on top of any BSP, converts it to a tuned for small systems
BSP. Other than that, we have to hold the line on BSP configurations.
Keep them tuned and specific by default and add kernel configurations
for optional features when request, not by default.

That's the approach we've been taking without our 150 or so
BSPs, and it has worked out really well for producing a
general/debug BSP + something that is tuned for a truly
embedded deployment.

Bruce

>
> Thoughts on this direction?
>

Re: 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

Re: Minimal images: kernel config

[Kang Kai]

On 2011年02月19日 03:15, Bruce Ashfield wrote:
> On 11-02-18 12:52 PM, 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.
>
> From the kernel angle, I have a profile/solution for this
> lurking in the 2.6.34 kernel, and one that we've been updating
> for the 2.6.37 kernel.
>
Hi Bruce,

> There's a kernel feature called "small", that when overlayed
> on top of any BSP, converts it to a tuned for small systems
> BSP. Other than that, we have to hold the line on BSP configurations.
> Keep them tuned and specific by default and add kernel configurations
> for optional features when request, not by default.
We are working on "minimal image". Right now we try to reduce rootfs 
size, but we think there are relationships between kernel configurations 
and rootfs, because rootfs also contains some kernel modules.
So would you send us a copy of kernel "small" configuration, more detail 
will be appreciated.

Thanks and Regards,
Kai
>
> That's the approach we've been taking without our 150 or so
> BSPs, and it has worked out really well for producing a
> general/debug BSP + something that is tuned for a truly
> embedded deployment.
>
> Bruce
>
>>
>> Thoughts on this direction?
>>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

Re: Minimal images: kernel config

[Bruce Ashfield]

On 11-04-27 01:38 AM, Kang Kai wrote:
> On 2011年02月19日 03:15, Bruce Ashfield wrote:
>> On 11-02-18 12:52 PM, 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.
>>
>> From the kernel angle, I have a profile/solution for this
>> lurking in the 2.6.34 kernel, and one that we've been updating
>> for the 2.6.37 kernel.
>>
> Hi Bruce,
>
>> There's a kernel feature called "small", that when overlayed
>> on top of any BSP, converts it to a tuned for small systems
>> BSP. Other than that, we have to hold the line on BSP configurations.
>> Keep them tuned and specific by default and add kernel configurations
>> for optional features when request, not by default.
> We are working on "minimal image". Right now we try to reduce rootfs
> size, but we think there are relationships between kernel configurations
> and rootfs, because rootfs also contains some kernel modules.
> So would you send us a copy of kernel "small" configuration, more detail
> will be appreciated.

Not ignoring this. Just swamped. I'll dig this up ASAP and
send it your way.

Bruce

>
> Thanks and Regards,
> Kai
>>
>> That's the approach we've been taking without our 150 or so
>> BSPs, and it has worked out really well for producing a
>> general/debug BSP + something that is tuned for a truly
>> embedded deployment.
>>
>> Bruce
>>
>>>
>>> Thoughts on this direction?
>>>
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>