[Toybox] BSD support

[Rob Landley]

On 01/20/14 08:37, Matthew Turk wrote:
>> I expect bsd will only ever support a subset of the commands, because we're
>> not afraid to be linux-specific. For example, things like ifconfig make
>> liberal use of /proc, my next wave of umount adds losetup -d support
>> (loopback) and -a support using /proc/mounts (or that horrible
>> /proc/mountinfo hack), my half-finished mount code grovels around in
>> /proc/filesystems trying to mount something you didn't tell it -t for...
>>
>> That said there's no reason stuff like sort and sed can't work equally well
>> on bsd.
>>
>> There is a lib/platform.h and lib/platform.c that you're welcome to add as
>> much bsd-specific glue to as you can stomach. Those are the places for them.
>
> (only somewhat related)
>
> I've recently ported toybox to run on Native Client, which is Google's
> in-browser runtime environment:
> https://code.google.com/p/naclports/source/browse/trunk/src/ports/toybox

Ooh, very interesting.

Is 
https://code.google.com/p/naclports/source/browse/trunk/src/ports/toybox/nacl.patch 
the only patch you're applying?

Where would I get the build environment, and how do you test it?

> .  I'm afraid I didn't know about these porting suggestions, so I've
> made some changes in the patch that are likely against the spirit of
> the porting instructions you've given above.  Anyway, I'm going to try
> to go through and clean it up, keeping these things in mind.  The
> biggest hurdle was getting a working getcwd, as NaCl has some quirks
> in that regard, and the various dirfd-taking *at commands.

I believe all of that's in posix-2008 now.

> The long and the short, though, is that Toybox is pretty great and was
> quite nice to get running in that environment.

Yay. I'm glad you find it useful.

I note that toysh is more or less a stub. I have elaborate plans for it, 
but haven't had time to actually implement most of them yet.

(Alas sitting down to a complex thing, it often takes me twenty minutes 
to reload all the context of what the heck I was doing last time, and if 
I only have half hour chunks to work on it I spend most of my time 
studying the code to figure out where I left off and what I was 
thinking. Large uninterrupted blocks of time I can tackle serious things 
with is at a bit of a premium these days. Day job gets almost all of it...)

In the case of toysh, it's got entire subsystems I've sketched out but 
not implemented yet. Environment variables (quote parsing itself is 
nontrivial: "$("$BLAH")" is fun...), job control, pipes and redirects...

I added a lot of config entries in part to act as a todo list, and I've 
left them there for that reason even though these days I'm actually 
leaining _against_ making commands extremely granular. I want each 
command implementation to be simple and straightforward, but I don't 
expect people to micromanage configuration decisions. Busybox has grown 
all sorts of crap like "CONFIG_DESKTOP" that controls whether find 
includes "-not" support (meaning in the current version you need to 
enable CONFIG_DESKTOP to get a busybox that can rebuild itself) and I 
just don't want to go there. "Can the busybox $BLAH command do X" should 
have one simple answer, not "it depends"...

Rob