[Toybox] BSD support

[Matthew Turk]

Hi Rob,

On Mon, Jan 20, 2014 at 11:01 PM, Rob Landley <rob at landley.net> wrote:
> 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?

Yup.  A number of the toys have been disabled, which you can see in
the toybox.config file.

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

The build environment is the NaCl SDK, which has a few steps to
installation.  Really you just need the SDK:

https://developers.google.com/native-client/dev/sdk/download

I believe pepper_canary has the patches I submitted that were required
to get toybox to compile.  After that, the naclports repo:

https://code.google.com/p/naclports/wiki/HowTo_Checkout?tm=4

SVN checkout is sufficient, but I made an hg mirror of the naclports
repo on bitbucket as well.  Building toybox is easiest with:

NACL_ARCH=pnacl make toybox

This will spit out a directory in
out/publish/toybox-0.4.7/pnacl/toybox/ with the .html, .pexe and some
javascript.  The toybox.html has to be accessed through a non-file://
URL (localhost is fine), but it will then run in chrome by visiting
toybox.html.  Arguments to the executable can be specified with
?arg1=... and so on.  The filesystem by default in this compile is
non-persistent.

I've put a build of this here:

http://yt-project.org/upload/toybox/toybox.html
( http://yt-project.org/upload/toybox/toybox.html?arg1=sh for the shell )


>
>
>> .  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.

Ah, great, thanks.

>
>
>> 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.

Understood.  Even as is, it ably serves the purpose I was looking for,
which is to provide a serviceable shell for navigating the mount
points and file systems used by the pexes in native client.  I'm going
to try to clean up the patch applied for NaCl, as I see from the
discussion here I've done some things sub-optimally.  As the NaCl SDK
grows to encompass more system calls and the like, I think more
compile-time options and toys can be turned on.

>
> (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"...

I found myself somewhat overwhelmed when I tried to compile busybox,
for precisely the reasons you suggest.

Thanks again for toybox -- and I empathize with the difficulties of
context switching.  Despite that, toysh works pretty well for
navigating the restricted environment I'm using it in!

-Matt

>
> Rob