I hate busybox!

I hate busybox!

[Paul D. DeRocco]

My embedded system has enough room in it for full-featured command line
tools, instead of the wretched busybox. Does the Yocto meta-data include a
layer that provides such tools? Or does OE? And how would I disable
busybox in order to use the better tools?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: I hate busybox!

[Paul Eggleton]

Hi Paul,

On Tuesday 15 September 2015 01:26:20 Paul D. DeRocco wrote:
> My embedded system has enough room in it for full-featured command line
> tools, instead of the wretched busybox. Does the Yocto meta-data include a
> layer that provides such tools? Or does OE? And how would I disable
> busybox in order to use the better tools?

core-image-full-cmdline (and the packagegroup it uses, packagegroup-core-full-
cmdline) should give you the former, and the full tools will in almost all 
cases take precedence simply by being installed by virtue of the alternatives 
system. In order to actually remove busybox though you'd need to break apart 
packagegroup-core-boot (i.e. include its constituent parts separately into 
your image instead of the packagegroup itself).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: I hate busybox!

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On 15 September 2015 at 09:45, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

> core-image-full-cmdline (and the packagegroup it uses,
> packagegroup-core-full-
> cmdline) should give you the former, and the full tools will in almost all
> cases take precedence simply by being installed by virtue of the
> alternatives
> system. In order to actually remove busybox though you'd need to break
> apart
> packagegroup-core-boot (i.e. include its constituent parts separately into
> your image instead of the packagegroup itself).
>

Wind River have started to send patches to enable this, so oe-core 2.0 may
be able to have images without busybox.

Ross

[-- Attachment #2: Type: text/html, Size: 1092 bytes --]

Re: I hate busybox!

[Trevor Woerner]

On 09/15/15 04:26, Paul D. DeRocco wrote:
> My embedded system has enough room in it for full-featured command line
> tools, instead of the wretched busybox. Does the Yocto meta-data include a
> layer that provides such tools? Or does OE? And how would I disable
> busybox in order to use the better tools?

+1

...although "hate" is a strong word, I have been tripped up numerous
times in the past by writing a script on my development host only to
find it doesn't work on my target device due to the restrictions of the
various busybox executables. The "embedded" system of today is the
desktop system of only a couple years ago. The only place busybox (and
toybox) are needed today are in the MMU-less-type systems, such as
Cortex-Ms etc.

Re: I hate busybox!

[Trevor Woerner]

On 09/15/15 10:47, Trevor Woerner wrote:
> The only place busybox (and
> toybox) are needed today are in the MMU-less-type systems, such as
> Cortex-Ms etc.

Actually, the presence or lack of MMU is irrelevant, I meant to single
out those systems with limited on-SoC flash.

Re: I hate busybox!

[William Mills]

On 09/15/2015 10:53 AM, Trevor Woerner wrote:
> On 09/15/15 10:47, Trevor Woerner wrote:
>> The only place busybox (and
>> toybox) are needed today are in the MMU-less-type systems, such as
>> Cortex-Ms etc.
> 
> Actually, the presence or lack of MMU is irrelevant, I meant to single
> out those systems with limited on-SoC flash.
> 

OE-core is capable of building a system that has no GPLv3.
This capability is still important to some users and busybox is needed
for that as I understand.

(Other users want the capability to build a system w/o proprietary code.
 OE serves both needs.)

Re: I hate busybox!

[Romain Perier]

Hi all,

I disagree,
Unfortunately some embedded devices in the industry are not like most
of the tablets and smartphones in the market (no quad or octo cores
with few GB of ram... and few GB of flash...)   ;)  .For example,
these days, at work, we're designing a board with the SoC zynq-7000
and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
kernel and my rootfs.

Embedded projects like uclibc, musl or busybox are very appreciated in
cases like this one :)

I am not saying that it is a great thing to have busybox built and
enabled by default, but that is a great thing to be able to use it.
In fact, it strongly depends on your needs for the target...

Regards,
Romain

2015-09-15 17:39 GMT+02:00 William Mills <wmills@ti.com>:
>
> On 09/15/2015 10:53 AM, Trevor Woerner wrote:
>> On 09/15/15 10:47, Trevor Woerner wrote:
>>> The only place busybox (and
>>> toybox) are needed today are in the MMU-less-type systems, such as
>>> Cortex-Ms etc.
>>
>> Actually, the presence or lack of MMU is irrelevant, I meant to single
>> out those systems with limited on-SoC flash.
>>
>
> OE-core is capable of building a system that has no GPLv3.
> This capability is still important to some users and busybox is needed
> for that as I understand.
>
> (Other users want the capability to build a system w/o proprietary code.
>  OE serves both needs.)
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: I hate busybox!

[Bob Cochran]

On 09/15/2015 12:38 PM, Romain Perier wrote:
> Hi all,
>
> I disagree,
> Unfortunately some embedded devices in the industry are not like most
> of the tablets and smartphones in the market (no quad or octo cores
> with few GB of ram... and few GB of flash...)   ;)  .For example,
> these days, at work, we're designing a board with the SoC zynq-7000
> and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
> u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
> kernel and my rootfs.
>
> Embedded projects like uclibc, musl or busybox are very appreciated in
> cases like this one :)
>
> I am not saying that it is a great thing to have busybox built and
> enabled by default, but that is a great thing to be able to use it.
> In fact, it strongly depends on your needs for the target...

Agreed.

I just tack on IMAGE_INSTALL_append = " tar findutils tree etc..." in my 
image recipe when I have the rootfs space, and I want the full tool. 
The build system seems to do a nice job of creating the links properly.


>
> Regards,
> Romain
>
> 2015-09-15 17:39 GMT+02:00 William Mills <wmills@ti.com>:
>>
>> On 09/15/2015 10:53 AM, Trevor Woerner wrote:
>>> On 09/15/15 10:47, Trevor Woerner wrote:
>>>> The only place busybox (and
>>>> toybox) are needed today are in the MMU-less-type systems, such as
>>>> Cortex-Ms etc.
>>>
>>> Actually, the presence or lack of MMU is irrelevant, I meant to single
>>> out those systems with limited on-SoC flash.
>>>
>>
>> OE-core is capable of building a system that has no GPLv3.
>> This capability is still important to some users and busybox is needed
>> for that as I understand.
>>
>> (Other users want the capability to build a system w/o proprietary code.
>>   OE serves both needs.)
>>
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: I hate busybox!

[Trevor Woerner]

On 09/15/15 13:01, Bob Cochran wrote:
> On 09/15/2015 12:38 PM, Romain Perier wrote:
>> Hi all,
>>
>> I disagree,
>> Unfortunately some embedded devices in the industry are not like most
>> of the tablets and smartphones in the market (no quad or octo cores
>> with few GB of ram... and few GB of flash...)   ;)  .For example,
>> these days, at work, we're designing a board with the SoC zynq-7000
>> and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
>> u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
>> kernel and my rootfs.
>>
>> Embedded projects like uclibc, musl or busybox are very appreciated in
>> cases like this one :)
>>
>> I am not saying that it is a great thing to have busybox built and
>> enabled by default, but that is a great thing to be able to use it.
>> In fact, it strongly depends on your needs for the target...
>
> Agreed.
>
> I just tack on IMAGE_INSTALL_append = " tar findutils tree etc..." in
> my image recipe when I have the rootfs space, and I want the full
> tool. The build system seems to do a nice job of creating the links
> properly.

This is merely an example of the exception being taken for the norm/default.

You'd be hard-pressed to find many boards that don't have an SD or
microSD slot for your bootloader, kernel, and filesystem image. And
you'd be hard-pressed to buy an SD/microSD card less than 8GB now-a-days.

Even amongst boards that have on-board flash, most of them have 1GB or
more with 4GB being quite common:

   
https://en.wikipedia.org/wiki/Comparison_of_single-board_computers#I.2FO_interfaces_and_ports

In any case, choice in deciding what goes into an image is good. I
simply think that, now-a-days, basing all images on busybox (and having
the option to swap some out) is rather quaint. The problem is: your
image doesn't have "ls", it has "busybox's ls". And your image doesn't
have "ps", it has "busybox's ps"... and those aren't the same. In most
cases I want the "real" utilities (the ones I've spent that last 20
years using) not some crippled version.

Ideally the basic OE images would be based on the real utilities (i.e.
the images that get built by default and tested by the Yocto Project's
QA machinery), and there would be a core-image-minimal-busybox (and
core-image-minimal-toybox) provided in those vanishingly rare cases
where they might be needed. Instead of the current situation where
busybox is the default, and some images swap out some of its components
for the real ones.

Re: I hate busybox!

[Bob Cochran]

On 09/15/2015 02:22 PM, Trevor Woerner wrote:
> On 09/15/15 13:01, Bob Cochran wrote:
>> On 09/15/2015 12:38 PM, Romain Perier wrote:
>>> Hi all,
>>>
>>> I disagree,
>>> Unfortunately some embedded devices in the industry are not like most
>>> of the tablets and smartphones in the market (no quad or octo cores
>>> with few GB of ram... and few GB of flash...)   ;)  .For example,
>>> these days, at work, we're designing a board with the SoC zynq-7000
>>> and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
>>> u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
>>> kernel and my rootfs.
>>>
>>> Embedded projects like uclibc, musl or busybox are very appreciated in
>>> cases like this one :)
>>>
>>> I am not saying that it is a great thing to have busybox built and
>>> enabled by default, but that is a great thing to be able to use it.
>>> In fact, it strongly depends on your needs for the target...
>>
>> Agreed.
>>
>> I just tack on IMAGE_INSTALL_append = " tar findutils tree etc..." in
>> my image recipe when I have the rootfs space, and I want the full
>> tool. The build system seems to do a nice job of creating the links
>> properly.
>
> This is merely an example of the exception being taken for the norm/default.
>
> You'd be hard-pressed to find many boards that don't have an SD or
> microSD slot for your bootloader, kernel, and filesystem image. And
> you'd be hard-pressed to buy an SD/microSD card less than 8GB now-a-days.
>
> Even amongst boards that have on-board flash, most of them have 1GB or
> more with 4GB being quite common:

Right, but I want to use FLASH to store a lot of nonvolatle R/W data, 
not just applications, libraries, and the kernel, so a couple GB doesn't 
go very far.

Do you know offhand how much bigger the rootfs would be if you build 
core-image-base without busybox and instead use the real applications?

Also, how many more packages have to be built / managed?

Thanks



>
>
> https://en.wikipedia.org/wiki/Comparison_of_single-board_computers#I.2FO_interfaces_and_ports
>
> In any case, choice in deciding what goes into an image is good. I
> simply think that, now-a-days, basing all images on busybox (and having
> the option to swap some out) is rather quaint. The problem is: your
> image doesn't have "ls", it has "busybox's ls". And your image doesn't
> have "ps", it has "busybox's ps"... and those aren't the same. In most
> cases I want the "real" utilities (the ones I've spent that last 20
> years using) not some crippled version.
>
> Ideally the basic OE images would be based on the real utilities (i.e.
> the images that get built by default and tested by the Yocto Project's
> QA machinery), and there would be a core-image-minimal-busybox (and
> core-image-minimal-toybox) provided in those vanishingly rare cases
> where they might be needed. Instead of the current situation where
> busybox is the default, and some images swap out some of its components
> for the real ones.
>

Re: I hate busybox!

[Paul D. DeRocco]

> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com] 
> 
> core-image-full-cmdline (and the packagegroup it uses, 
> packagegroup-core-full-
> cmdline) should give you the former, and the full tools will 
> in almost all 
> cases take precedence simply by being installed by virtue of 
> the alternatives 
> system. In order to actually remove busybox though you'd need 
> to break apart 
> packagegroup-core-boot (i.e. include its constituent parts 
> separately into 
> your image instead of the packagegroup itself).

That was pretty painless, since I don't actually need to remove busybox.
Thanks.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: I hate busybox!

[Paul D. DeRocco]

> From: Bob Cochran
> 
> Do you know offhand how much bigger the rootfs would be if you build 
> core-image-base without busybox and instead use the real applications?
> 
> Also, how many more packages have to be built / managed?

I just added packagegroup-core-full-cmdline to my image, and it increased
the size by about 36MB. That's on a 32-bit Intel system. I don't know how
many packages are in that group, but all I had to do was add that one word
to my IMAGE_INSTALL, so I don't really care.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: I hate busybox!

[Khem Raj]

> On Sep 15, 2015, at 7:47 AM, Trevor Woerner <twoerner@gmail.com> wrote:
> 
> On 09/15/15 04:26, Paul D. DeRocco wrote:
>> My embedded system has enough room in it for full-featured command line
>> tools, instead of the wretched busybox. Does the Yocto meta-data include a
>> layer that provides such tools? Or does OE? And how would I disable
>> busybox in order to use the better tools?
> 
> +1
> 
> ...although "hate" is a strong word, I have been tripped up numerous
> times in the past by writing a script on my development host only to
> find it doesn't work on my target device due to the restrictions of the
> various busybox executables. The "embedded" system of today is the
> desktop system of only a couple years ago. The only place busybox (and
> toybox) are needed today are in the MMU-less-type systems, such as
> Cortex-Ms etc.

I agree on busybox differences but sometimes its not about the utilities they are needed for some sundry work.
What would be interesting to know is how much size increase is caused by replacing all busybox functionality
with other utilities and also RAM consumption. That can give valuable information for someone who is assembling embedded system stack and help him/her the decision making. embedded systems of today might have more memory and what not, but they are also running more
complex applications than in past, so software bloat has caught up with more memory, in the end you still need to be cautious about the footprint and equation remains almost same.

I believe once we have a busybox replacement package group we can get the information I asked in para 1 which is a good thing.

Re: I hate busybox!

[Paul D. DeRocco]

> From: Khem Raj [mailto:raj.khem@gmail.com] 
> 
> I agree on busybox differences but sometimes its not about 
> the utilities they are needed for some sundry work.
> What would be interesting to know is how much size increase 
> is caused by replacing all busybox functionality
> with other utilities and also RAM consumption. That can give 
> valuable information for someone who is assembling embedded 
> system stack and help him/her the decision making. embedded 
> systems of today might have more memory and what not, but 
> they are also running more
> complex applications than in past, so software bloat has 
> caught up with more memory, in the end you still need to be 
> cautious about the footprint and equation remains almost same.

As I said in another message, my 32-bit Intel system image increased by
36MB when I added the full utilities. The busybox executable is half a
meg, while individual full-featured commands are generally a few tens of
kilobytes. I don't know if running busybox loads the whole thing into
physical RAM, or if it only allocates the pages that are actually touched;
that would determine the relative RAM use, I suppose.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: I hate busybox!

[Mike Looijmans]

On 16-09-15 03:13, Khem Raj wrote:
>> On Sep 15, 2015, at 7:47 AM, Trevor Woerner <twoerner@gmail.com> wrote:
>> On 09/15/15 04:26, Paul D. DeRocco wrote:
>>> My embedded system has enough room in it for full-featured command line
>>> tools,...
"Embedded" in my world is not about RAM or disk size. It's about 
building a device that has a set task in life, and nothing is as 
important as that one task. Whether that's running on an i7 or an M3 is 
irrelevant.

For a system to acquire and process sensor data, record your favorite TV 
shows, or guide a missile, there's no need for a full fledged bash shell 
interpreter. It just needs a bit of plumbing to get the application up 
and running, and that's about it.

Busybox is for systems like that. For these systems, anything more is 
overkill, and will waste resources and increase the boot time.

Re: I hate busybox!

[Paul D. DeRocco]

> From: Mike Looijmans
>
> "Embedded" in my world is not about RAM or disk size. It's about 
> building a device that has a set task in life, and nothing is as 
> important as that one task. Whether that's running on an i7 
> or an M3 is irrelevant.
> 
> For a system to acquire and process sensor data, record your 
> favorite TV 
> shows, or guide a missile, there's no need for a full fledged 
> bash shell 
> interpreter. It just needs a bit of plumbing to get the 
> application up 
> and running, and that's about it.
> 
> Busybox is for systems like that. For these systems, anything more is 
> overkill, and will waste resources and increase the boot time.

If you've got a 1GB eSSD drive, because that's the smallest you can buy,
having a 382MB image rather than a 346MB image isn't a waste of anything.
How much boot time increase do you think you'll get from full-featured
command line tools? I'd be surprised if it was noticeable to anyone.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: I hate busybox!

[Khem Raj]

On Wed, Sep 16, 2015 at 9:43 AM, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
> If you've got a 1GB eSSD drive, because that's the smallest you can buy,
> having a 382MB image rather than a 346MB image isn't a waste of anything.
> How much boot time increase do you think you'll get from full-featured
> command line tools? I'd be surprised if it was noticeable to anyone.

Thats one usecase and there are so many other. Usually, you want to be
mindful about OS overhead especially in embedded systems
in todays time it may be sufficient you may want to recover that space
in 5 years down the line. It depends on usecases but generally
being mindful about resource usage is always beneficial in products
life cycle embedded systems sometimes live for a very long time in
field

Generally when you have systemd which copy images to RAM and then run
from RAM would not want that extra 50 odd Megs gone
for storing extra tools in some case.

As long as we keep supporting the most common ones along with fringe
cases but with less priority we are OK.

Re: I hate busybox!

[Paul D. DeRocco]

> From: Khem Raj [mailto:raj.khem@gmail.com] 
> 
> Generally when you have systemd which copy images to RAM and then run
> from RAM would not want that extra 50 odd Megs gone
> for storing extra tools in some case.

Do you mean systemd or syslinux?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: I hate busybox!

[Khem Raj]

On Wed, Sep 16, 2015 at 2:07 PM, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
> Do you mean systemd or syslinux?

none of these it was typo it should be read as 'systems'

Re: I hate busybox!

[Mike Looijmans]

On 16-09-15 18:43, Paul D. DeRocco wrote:
>> From: Mike Looijmans
>>
>> "Embedded" in my world is not about RAM or disk size. It's about
>> building a device that has a set task in life, and nothing is as
>> important as that one task. Whether that's running on an i7
>> or an M3 is irrelevant.
>>
>> For a system to acquire and process sensor data, record your
>> favorite TV
>> shows, or guide a missile, there's no need for a full fledged
>> bash shell
>> interpreter. It just needs a bit of plumbing to get the
>> application up
>> and running, and that's about it.
>>
>> Busybox is for systems like that. For these systems, anything more is
>> overkill, and will waste resources and increase the boot time.
>
> If you've got a 1GB eSSD drive, because that's the smallest you can buy,
> having a 382MB image rather than a 346MB image isn't a waste of anything.

To me it looks like a waste of 36 MB that could have been used for storing 
useful data.

For many projects, 36MB is more than I have for the whole root filesystem. 
Usually I get between 8 and 32 MB for the whole system (bootloader, kernel, 
rootfs and user data storage).

> How much boot time increase do you think you'll get from full-featured
> command line tools? I'd be surprised if it was noticeable to anyone.

My current boot time is about 4 seconds. The SD memory on this board reads at 
roughly 20MB/s, so each MB that I need to read at boot will cost me 50ms 
extra. That is most certainly measurable. The NAND flash reads at 10MB/s, so 
that'll be 100ms per megabyte.


As I said before, you and I live in different worlds. From where I'm standing, 
your system is the exception, not the rule.