[Toybox] BSD support

[Matthew Turk]

On Wed, Jan 22, 2014 at 4:33 PM, Rob Landley <rob at landley.net> wrote:
> On 01/21/14 12:27, Matthew Turk wrote:
>>>>
>>>> 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.
>
>
> Possibly I can chip a few bits out of that myself and put 'em in platform.h.
> Some of it looks quite straightforward. (Taken as a whole, reading it
> requires some eye bleach though. Redefining main() like that... better to
> move the non-main bits out of main.c and have the ability to pull in a
> different main.c for embedded builds...)

Ha!  I wish I could levy the blame for the eye-bleach patch at someone
else, but nope, that's all my fault.  And I agree with your assessment
of main; in fact, the way the nacl_io setup is now, you have to do all
your mounts and unix environment setup inside the main module section,
which leads to lots of duplication of code across different modules.

For the next version of the patch, I'll yank the changes to main out
and instead link against another .c file that manages them.

>
>
>> A number of the toys have been disabled, which you can see in
>> the toybox.config file.
>
>
> Indeed.
>
>
>> 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 )
>
>
> "Browser does not support PAnCL or PAnCL is disabled."
>
> I take it I need a chrome box to run this?
>
> Where do I read up on "what is nacl"?

Hm, recent versions of chrome should support it out of the box.  I run
Chrome beta (33) on (non-ChromeOS) linux and it runs just fine.  The
best place to read up is on gonacl.com, although I think the docs
trail the SDK source by small amount.

>
>
>>>> .  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.
>
>
> I'd very much like to get a "what's the diff for posix-2013", given that
> https://lwn.net/Articles/581858/ and such are using the name. It'd be nice
> to be able to say posix 2013 compliant, but the snapshot I've been working
> on is posix-2008 (already did the move from the posix-2003 that was out when
> I started this in 2007), and I don't want to completely re-triage
> everything...
>
> Alas, they talk about an annex but I can't _find_ it broken out. When I try
> to diff the html pages I get lots of markup differences because the
> generator changed...
>
>
>>>> 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.
>
>
> Well, the next big lump is environment variables, which implies quote
> parsing. Getting quote parsing right is five times as much work as anything
> actually to do with environment variables. :)
>
>
>> 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.
>
>
> md5sum/sha1sum looks low-hanging?

Good idea, yes.

>
> There's a fairly large lump of stuff added to lib/portability.c that looks
> like it really belongs in nacl's libc or something?

Yes, it definitely does.  I submitted a few patches, and have hopes of
submitting patches for all of the *at commands, but I have not yet
completely understood the plumbing to connect untrusted code to the
trusted runtime.

>
> It might even be enough to justify me replacing lib/portability.c with a
> lib/portability directory containing individual C files, but how to select
> 'em is a big enough bother I'd probably hold off for now...
>
> Always more todo items...
>
>
>> 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!
>
>
> Well, here's hoping I can make it better...
>
> (But this weekend, I need to get an aboriginal linux release out caught up
> with the 3.13 kernel...)

Good luck!  Thanks for the kick in the pants about the patch; I'll try
to make it a bit less invasive in future iterations.

-Matt

>
> Thanks,
>
> Rob