lua [ was: Bash shell support? ]

Rob Landley rob at landley.net
Mon Aug 28 20:51:04 UTC 2006


On Monday 28 August 2006 4:01 pm, Bernhard Fischer wrote:
> On Mon, Aug 28, 2006 at 03:31:47PM -0400, Rob Landley wrote:
> >On Monday 28 August 2006 6:28 am, Bernhard Fischer wrote:
> >> Why on earth do we want any scripting _in_ busybox?
> >
> >You mean like lash, msh, hush, ash, and bbsh?
> 
> Nah.. If you start with those, then one would have to add sed, awk,
> ed,.. too, with may be strictly correct but not strictly a
> scripting-language. They are implementing established tools, at least.

I'm saying that we _have_ a scripting language.  Shell scripts.  (And if they 
get nofork versions of sed and awk they get noticeably faster.  Still a pain 
to use, but oh well.)

Lua came up because someone had a patch, and the size estimate sounded 
appealing.  The new size estimate is less appealing, and the pending 
patchness seems to have receeded a bit.  I'm not pursuing lua support, I'm 
just not resisting it the way I would, say, perl. :)

For 1.3.0, my priority is fixing/rewriting the stuff we've already _got_ in 
busybox.

> >> AFAIR, we don't want (resp. didn't want until recently) these in busybox
> >> -) filesystem utilities (bad example as there currently is a big bloated
> >>    batch in there -- e2fsprogs -- that noone cares to shrink nor really
> >>    maintain)
> >
> >Actually I'm about 1/2 way through a from-scratch mke2fs rewrite.  
> 
> Don't get me wrong, but that one is utterly and completely offtopic at
> any rate. There are much more worthwile things to cleanup that are
> generally useful, except filesystem maintenance stuff.

Yeah, but in terms of "ok, what's the easiest way to chop the next 20k off of 
the make defconfig busybox binary", the e2fsprogs directory bubbles right to 
the top. :)

Making it GO AWAY is kind of satisfying...

> I'd have turned e2fsprogs off in about all *config targets for a loong
> time, if it was up to me. Same for the partitioning stuff.

fdisk and ash are two of the other whales in the code, yes.  And both are on 
my hit list, I'm just a touch overextended these days so it's happening 
slowly...

> These make up 
> for a nice "Extra tools" config submenu that is off by default and
> states that it is mostly bloat and seldom used anyway -- just add a
> full-blown sfdisk or xyz_fsprogs if you really think you need to
> support/provide it.

Well, ext2 is the default linux filesystem.  I personally don't care in the 
slightest about reiserfs and although xfs is cool it doesn't belong in 
busybox.  But mke2fs gets us both ext2 and ext3, and there's a certain appeal 
to that.

> [snip i-have-to-meet-deadlines-too]
> >> -) compilers (i'd immediately put in tcc, because it is relatively small
> >>    -- <100k -- and relatively useful, as in somewhat useable C89 support)
> >
> >I'd like BusyBox to build with tcc.  (I subscribed to the tcc mailing list 
but 
> >have yet to get a message on it.)  If I had more time I'd try to get that 
to 
> >be a better gcc replacement (for starters, building the kernel...)
> 
> build with != incooperate with. My cp of tcc is <100k and compiles most
> of busybox (modulo sed and other ...stuff).

Cool.  I play with it here from time to time by just going "CC=tcc" isn't 
enough to build most things.  (Heck, sometimes when I build and install it I 
can't even get the sucker to build "hello world".  Not sure why, haven't 
tracked it down...)

> >Seems a bit stalled now that Fabrice has his hands full with qemu...
> 
> Unfortunate but true. Could need a different upstream, as it stands ;-)

If I had more time, I'd contribute to it.  And the kernel.  And uClibc.  And 
qemu.  and...

Alas, I need a year vacation just to work on busybox to get it where I'm not 
drowning in longstanding todo items...

> >> One project that may be of real use is to export a zlib compatible
> >> interface, as mentioned before, but i didn't yet see any proposal for
> >> this one.
> >
> >If someone would like to do this, I'm all for it.  (It's probably best if 
> >libbb.so did this.  When I cycle back around to working on 
scripts/individual 
> >again, I need to not just fix the rest of the apps to build right but add 
> >libbb.so support.)
> 
> Trivial since all the major bits are already in place :)

I almost said "trivial" and then backspaced because if it was I'd have already 
done it.  But not a major project. :) 

> >Oh, a recent discussion on linux-kernel suggested that the "build at once" 
> >mode should be a separate target (which seems obvious in retrospect), and I 
> >think possibly libbb.so should also be a separate target.
> 
> No idea what that could be, TBH. Sounds like it's just fixups for
> non-GNU-complete drop-in libc's, ultimatively. Dunno, though.

No, I meant selecting things like "build at once" vs building each .c file one 
at a time via the make command line rather than in menuconfig.  However, if 
we can override config symbols from the command line (which I think we can if 
only ) we should be able to do this.

> >Possibly we should have a number of targets:
> >
> >busybox (default)
> >busybox-static
> >busybox-shared (with libbb.so automatically built).
> >
> >Maybe these are .dummy targets, or maybe actual executable names.
> 
> Well, that's what 'make *config' is for, isn't it? ;)

Yes and no.  Features and packaging decisions aren't quite the same thing.  
I've already broken the cross-compile stuff out because you might want to 
build the same busybox for three different platforms.  I'm thinking that 
whether or not the result should be statically, dynamically, or 
monolithically linked is potentially also a build decision.

Currently just toying with the diea...

> Given the current brokenness of lxdialog, i'm all in favour of adhering
> to the caveats of the kernel's fork of dialog an plain not using it.
>
> From what i've seen, it is a pain to beat into collaboration and
> furthermore clearly states that it is expected to be. YMMV, resp.
> clearly does..

I don't know what you mean here.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list