[Toybox] ToyBox as an embedded C library

[Rob Landley]

On 12/26/13 14:41, Mrad Chems Eddine wrote:
> On 26/12/2013 05:36, Rob Landley wrote:
>> Do you mind if I respost this answer to the toybox list?
> Yes, of course do whatever you want with the post.

Once again, I'm amused that thunderbird wordwrapped the text below but 
if you cut and paste the same wordwrapping it won't quite accept it 
because Thunderbird!

Oh well, it's less incomptent than Balsa. (Which is saying _nothing_...)

On 12/24/13 15:35, Mrad Chems Eddine wrote:
 > On 24/12/2013 04:17, Rob Landley wrote:
 >>
 >> Toybox isn't a C library, musl-libc.org is a C library. Toybox is an
 >> implementation of various command line tools.
 >
 > Yes, I know that. My idea is to release a C library similar to Toybox to
 > be used in a host application where it can execute Unix commands in
 > process without the cost of a fork(), exec(), etc. instead of standalone
 > binary like yours. What do you think?

Ah, you mean _shared_ library. Got it.

In theory, some commands may be run nofork, meaning they run in the same 
process context and return without leaking resources.

In practice, that's a fairly smallish number of the total. I have vague 
plans to make more of them work like that, but at the moment commands 
often leak memory and filehandles and memory mappings and such and 
expect exit() to clean up after them.

Also, the response to errors is to exit via error_exit() and such. (Most 
of the lib/xwrap.c functions exit on error instead of returning, that's 
what the x prefix means.) Now I made error_exit() call xexit() instead 
of exit(), whih has an option to longjmp() back to the caller instead of 
exiting. But nothing's particularly using that at the moment (when i get 
back to toysh, that's on the todo list).

And this is why the leaked resources are hard to fix, because if you 
abort in the middle of a command, how do you clean up its leaked memory 
and filehandles and such? (I have some ideas, but they're fairly 
intrusive. I could wrap/track all the resource allocations, do brittle 
groveling through /proc to find and free stuff, have the longjmp return 
to cleanup code...)

Combining fork() with a function call is more lightweight than exec(), 
and exit() can still clean up after it. But it's not nommu friendly, and 
if commands nest deeply (nice setsid detach...) it can eat who knows how 
much stack. So maybe it needs some sort of recursion limit where it does 
an exec() anyway...

It's possible that for gluing this into u-boot or something, exit() 
could just be replaced with halt() as the errors are generally "this 
should never happen, it's not recoverable if it does".

Do you mind if I respost this answer to the toybox list?

Rob