Embedded system use busybox in order to decrease system size. However current baselayout shell scripts use feature (find negation, find or'ing, grep -o option), that are not available in the busybox implementation of theses program. In order to make gentoo easily installable on embedded device, baselayout should probably be modified to only use busybox available features. Attached is a patch that fix the find issue in bootmisc when used in conjonction with busybox. Reproducible: Always Steps to Reproduce:
Created attachment 36983 [details, diff] Make bootmisc work with busybox
This patch only affects bootmisc. What about things like net.eth0? Do the rest of the scripts in baselayout already work with busybox or will they need modification as well? I'm not denying this patch but want to understand the future ramifications of making baselayout busybox-friendly. In other words, is this the only patch you need, or is this the start of a stream of patches to make all of baselayout work with busybox? Also, have you looked at baselayout-lite? That is another baselayout (with which I'm not familiar) that seems to be targetted at embedded systems. Just wondering.
There are several issues to fix. This patch only fix one of theses issues. net.eth0 has several problem with the usage of the grep -o parameter. Before even trying to fix this, we have to agree whether it sound okay to you to make baselayout busybox friendly... Another example of a shell script using grep -o is localmount. For now I didn't experienced other issues than the one I'm talking about here, but there are most probably others to be discovered by differents users. Also, I'm aware of baselayout-lite but I don't believe it's the way to go, at least not for people that want an easy to setup embedded system. I think we should try to provide an easy way to create such systems, without changing gentoo users habbit too much: using a generic baselayout as far as possible.
I'd like to get Azarah's input on this. I'm really torn. I like the idea of baselayout being embedded friendly, but I don't like the idea of being restricted to the busybox list of features. In particular it bothers me because it sounds like the features not supported by busybox are kind of random (for example lack of negation for the find command). Anyway, we'll see what Az thinks.
for now we use baselayout-lite with embedded
Yoann, With busybox/libc/baselayout what other deps are in your envionment? I don't see any reason why we should not make baselayout more friendly (not policy) if we can. It would probably even help out as our distro starts to evolve into other areas (embedded/bsd/macos/other..) where the std gnu tools are not there.
for now though i think this should be a development effort on the part of embedded peeps ... once we have a large number of fixes for baselayout, then we should bug agriffis/azarah for inclusion
Spanki: Baselayout lite is all but functionnal. See my original comment. Maintaining a large set of patch is a bad idea. It would be much harder to keep the patch in sync with std baselayout modification. What you are proposing is a fork of baselayout til someone decide to implement the modification back. That seem to be a bad idea to me. Solar: With standard baselayout: gawk, bash, sysvinit, util-linux.
Created attachment 37011 [details, diff] Workaround localmount grep -o / -w usage for busybox
Created attachment 37014 [details, diff] Bashrc fix test for dircolor + busybox grep friendlyness
<SpanKY> yoann: that's nice ... thats what opinions are good for My problem is that your opinion is lacking any technical ground. It doesn't take into account people arguments so far, and act rather strange by marking 'resolved' a bug there is discussion for without even asking others opinion. I don't call this openess of mind. <SpanKY> sending small patches to baselayout for inclusion isnt the way to go <SpanKY> once you have a set of patches that isnt full of hacks and/or incomplete support, you bring the work to baselayout <SpanKY> otherwise you waste their time with stuff they could care less about Are you the busybox maintainer? Because some people seem to have a different opinion from you. Mind to give concrete argument instead of flaming? "Incomplete support": of course there is a lot to do. "Hack": either shut up, or come with something better or a guideline on how to do it. Your reaction is going to get you one things: loss of one contributor. You see, I have a need to setup an embedded system for my work, and I thought I might as well contribute things back to the community. I'm affraid that your reaction will result in me stopping contribution and doing thing in my corner without giving anything back. If it's not what you want, then I urge you to change your way of handling this things.
s/busybox/baselayout/
I think you should rather point out issues that busy-box have with current scripts, as I am not sure with your changes. I however do not like how you changed things, so would rather want to know what exactly the issue is.
As pointed out earlier, the problem is that you can't use GNU specific options with busybox. Even some standard option has been stripped out for size requirement. From memory: - GNU awk extension should not be used. - grep -m option is not available. - grep -o option is not available. - grep -w option is not available. - grep -x option is not available. - find doesn't support expression negation/or'ing - find doesn't support --exec If you fix theses issue (which the patch attached partly does), then you fix the majority of the problem with standard gentoo on busybox enabled system. We could then see a future where the user would only have to set an USE flags in order to setup an embedded system.
Azarah what do you not like about the changes? Most of them are simple. GNU - awk ; yeah that's probably another story but most of the other things can be worked around rather trivially as these patches show. In any event I'm for them as baselayout-lite is not proving to be all that ideal. IE for baselayout-lite an entire runscript/runscript.sh and functions.sh replacement has to be written. (which we lack the time for right now)
I've talked with Az about this, and I can gather Spanky's opinion from this bug. ;-) I'm not going to take this patch at this point. Here are my reasons: First, I don't think that we're going to be able to keep baselayout busybox-friendly. We develop against the GNU toolset. Sure, we could stick in a couple patches to make it busybox-friendly, but we're going to break it every time we make changes because we're not developing against busybox. I don't think this is a pattern we want to get into. As yoann mentioned earlier, "we have to agree whether it sound okay to you to make baselayout busybox friendly..." I don't think we should attempt. It's going to be a constant tug of war between the embedded people wanting it to work well with busybox, and the baselayout developers trying to add functionality. Second, baselayout-lite exists for embedded systems. Yoann said, "I don't believe it's the way to go, at least not for people that want an easy to setup embedded system." I really don't understand this reasoning. If the system you're trying to build is small enough that it requires busybox, then I don't think that it probably needs the features of baselayout. On the other hand, if it needs the features of baselayout, then it is probably big enough to tolerate the GNU toolset. So I think this leaves you with a few choices: 1. use and improve baselayout-lite 2. fix the missing functionality in busybox so that it incorporates the same features as the GNU toolset 3. use the GNU toolset
<SpanKY> yoann: that's nice ... thats what opinions are good for you took that wrong ... that was in response to you calling me stupid ... it had nothing to do with this report as for my opinion for support in baselayout, i would like to see it updated to support busybox, but i dont think the patches cover everything ... i could be wrong, but like you so kindly pointed out, i'm not the direct maintainer of baselayout so i guess my opinion doesnt matter huh *shrug*
Sorry yoann I guess your fuqed then.. Maybe in 3-4 months you will be able to use something.
If I can step in for a moment. Baselayout is handled for the most part by Azarah and agriffis. Vapier, however, is one of the more crucial members of the gentoo development team in general, and the base system (AND embedded) team in particular, so his opinion is very highly regarded. I can see that you may have taken his wording wrongly initially and ascribed a tone that he hadn't intended, but please take my word for it -- vapier is not only cunningly analytic and intelligent, but he's also a really nice guy with a sense of humour. Almost sounds like I'm trying to pimp him, I guess, but them's the facts.
My reaction was harsh due to the way you marked this bug as resolved, and it seemed you didn't care about it. This was the reason. If we goes for supporting baselayout, then I think you should apply the patch incrementally, so that it don't because a maintaining mess. As for baselayout-lite: it's not working, and it's designed to do an highly customized system. Nothing similar to standard gentoo. My goal in making baselayout busybox friendly is a solution to have an embedded distribution that doesn't change the gentoo std way of doing things. People who want a completly customized system (no bash, etc) will still be able to use baselayout-lite when/if it is ready.
The question is still - how painful will it be to fix busybox ? Or have anybody tried to compile grep/find/whatever against klibc and if it generates small enough binaries? Lastly, not using gawk extensions will do two things: 1) Have to uglyfy the code more with using system() 2) make it much more expensive (slow) due to the lot of forks (And yes, it will be a few seconds on a slow box)
Changing busybox's grep is not really an option in this case as it would take substantially more code in the binary than our base init scripts. gawk - busybox's awk has nowhere near the functionality that gnu awk has so that's probably not an option to consider just yet. I don't think this bug is really about doing a complete busybox overhaul to baselayout but just enough to get a bootable system that will work with most of the initscripts we have. Gentoo-Lite if you will. baselayout-lite was designed for embedded systems that are of bootfloppy size, but it's not usable as we have pointed out. Main reason there is when you install anything into an the alt ROOT= that includes it's own initscript it will break the baselayout-lite which is more or less (assuming a non bash environment) Also just as a side note embedded was one of the #1 topic's at this years LWE and people are looking towards gentoo as being an ideal staging platform.
Comment on attachment 37014 [details, diff] Bashrc fix test for dircolor + busybox grep friendlyness we dont use `dircolors` anymore
