Re: [yocto] I hate busybox!
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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
On 16-09-15 03:13, Khem Raj wrote: On Sep 15, 2015, at 7:47 AM, Trevor Woernerwrote: 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
On Wed, Sep 16, 2015 at 2:07 PM, Paul D. DeRoccowrote: > Do you mean systemd or syslinux? none of these it was typo it should be read as 'systems' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> From: Khem Raj [mailto:raj.k...@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 Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
On Wed, Sep 16, 2015 at 9:43 AM, Paul D. DeRoccowrote: > 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> 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 Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> On Sep 15, 2015, at 7:47 AM, Trevor Woernerwrote: > > 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> From: Paul Eggleton [mailto:paul.eggle...@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 Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> From: Khem Raj [mailto:raj.k...@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 Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
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: 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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] I hate busybox!
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 Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
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: > > 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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
On 15 September 2015 at 09:45, Paul Eggletonwrote: > 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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
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: [yocto] I hate busybox!
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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto