<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 20, 2014 at 10:01 AM, Zack Breckenridge <span dir="ltr"><<a href="mailto:zbrdge@gmail.com" target="_blank">zbrdge@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><p dir="ltr">> There is a lib/platform.h and lib/platform.c that you're welcome to add as<br>
> much bsd-specific glue to as you can stomach. Those are the places for them.</p>
</div><p dir="ltr">I will try to see what I can do in there. Last night I attempted a first shot at simply compiling Toybox with GCC on a Debian GNU/kFreeBSD virtual machine. It was an interesting experiment as simply issuing 'make defconfig && make' works out of the box (after making sure gcc, and some linux kernel headers are installed of course).</p>
<p dir="ltr">I got a list of some 90 or so errors that point to missing header files or probably linux-isms as a nice starting point. Next I'll probably try and narrow these down into a todo list.</p><div class="im">
<p dir="ltr">> I expect bsd will only ever support a subset of the commands, because we're<br>
> not afraid to be linux-specific. For example, things like ifconfig make<br>
> liberal use of /proc</p>
</div><p dir="ltr">Personally, I think it would be great to have (nearly) every Toybox command work on FreeBSD somehow even if that means adding some kind of emulation shim, or forcing extra requirements on BSD users. For example, I know if you 'kldload' the Linux emulation kernel module on FreeBSD you get an emulated Linux proc filesystem to work with.</p>
<p dir="ltr">Also, it sounds like some of those types of 'shims' may already be written in the Native Client port by Matthew Turk, so I will certainly take a look at that!</p>
<p dir="ltr">Thanks,</p>
<p dir="ltr">Zack</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Jan 20, 2014 7:37 AM, "Matthew Turk" <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Rob,<br>
<br>
On Mon, Jan 20, 2014 at 9:30 AM, Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>
> On 01/20/14 02:36, <a href="mailto:ibid.ag@gmail.com" target="_blank">ibid.ag@gmail.com</a> wrote:<br>
>><br>
>> On Sun, Jan 19, 2014 at 09:25:57PM -0700, Zack Breckenridge wrote:<br>
>>><br>
>>> Hello all,<br>
>>><br>
>>> I understand that this project is Linux focused, but I can't help but<br>
>>> wonder if there would be any positive reception to 'porting' Toybox to<br>
>>> FreeBSD (and possibly OS X)?<br>
>>><br>
>>> I would like to contribute to the project regardless (these are my<br>
>>> three main platforms), and I suppose this could be a much larger<br>
>>> undertaking than I'm prepared for. Simply curious. Has this been<br>
>>> discussed already and apologies if so.<br>
>>><br>
>><br>
>> As I recall, Rob has mentioned the idea of porting it, but ran into<br>
>> difficulties getting a QEMU image for testing.<br>
><br>
><br>
> I had a thread with Joe Nosay (cc'd). I met Kirk McKusick at Ohio LinuxFest<br>
> and told him I couldn't get net, free, or OpenBSD to install under qemu, and<br>
> he recommended PCBsd. I got that to install, but the package management<br>
> system in the thing doesn't work to install anything not in the base image<br>
> (such as mercurial).<br>
><br>
> Given that it's not 1997 anymore, I find this somewhat limiting...<br>
><br>
><br>
>> So the FreeBSD port should be welcome...if it's done cleanly.<br>
>><br>
>> Anyhow, things to watch out for:<br>
>> #ifdef __PLATFORM:<br>
>> Somewhere, Rob's got a link to "#ifdef considered harmful".<br>
><br>
><br>
> It's linked from <a href="http://landley.net/toybox/code.html" target="_blank">http://landley.net/toybox/code.html</a><br>
><br>
> There's more advice on <a href="http://landley.net/toybox/cleanup.html" target="_blank">http://landley.net/toybox/cleanup.html</a> but that page<br>
> is still only half-done...<br>
><br>
><br>
>> We try to avoid #ifdef because it obscures the bigger picture, and<br>
>> when it's needed, we try to isolate it (better to have one header full<br>
>> of ifdefs than a dozen files...)<br>
>><br>
>> Non-portable includes:<br>
>> These should _never_ go in toys.h.<br>
>> I suspect this might mean adding "toy-platform.h" or something similar.<br>
>><br>
>> Non-portable functions:<br>
>> I think there's some sort of probing that the toybox build system does...<br>
>> See lib/portability.c for how we handle some missing functionality.<br>
>><br>
>> "Portable" is more-or-less "That portion of POSIX 2008 that is widely<br>
>> implemented", afaict.<br>
><br>
><br>
> I'm using Posix, LSB, the Linux man pages, and actual testing against other<br>
> implementations (especially trying to build linux from scratch).<br>
><br>
> Posix is the only one where I need a good excuse _not_ to do what it says<br>
> (preferably including a comment in the command implementation that we've<br>
> deviated, such as the one in toys/posix/who.c). LSB and the man pages are<br>
> advisory.<br>
><br>
><br>
>> Also, be sure to check whether it makes sense to use a command on the<br>
>> kernel you are porting to. pivot_root may well be irrelevant for you.<br>
><br>
><br>
> I expect bsd will only ever support a subset of the commands, because we're<br>
> not afraid to be linux-specific. For example, things like ifconfig make<br>
> liberal use of /proc, my next wave of umount adds losetup -d support<br>
> (loopback) and -a support using /proc/mounts (or that horrible<br>
> /proc/mountinfo hack), my half-finished mount code grovels around in<br>
> /proc/filesystems trying to mount something you didn't tell it -t for...<br>
><br>
> That said there's no reason stuff like sort and sed can't work equally well<br>
> on bsd.<br>
><br>
> There is a lib/platform.h and lib/platform.c that you're welcome to add as<br>
> much bsd-specific glue to as you can stomach. Those are the places for them.<br>
<br>
(only somewhat related)<br>
<br>
I've recently ported toybox to run on Native Client, which is Google's<br>
in-browser runtime environment:<br>
<a href="https://code.google.com/p/naclports/source/browse/trunk/src/ports/toybox" target="_blank">https://code.google.com/p/naclports/source/browse/trunk/src/ports/toybox</a><br>
. I'm afraid I didn't know about these porting suggestions, so I've<br>
made some changes in the patch that are likely against the spirit of<br>
the porting instructions you've given above. Anyway, I'm going to try<br>
to go through and clean it up, keeping these things in mind. The<br>
biggest hurdle was getting a working getcwd, as NaCl has some quirks<br>
in that regard, and the various dirfd-taking *at commands.<br>
<br>
The long and the short, though, is that Toybox is pretty great and was<br>
quite nice to get running in that environment.<br>
<br>
-Matt<br>
<br>
><br>
> Rob<br>
><br>
> _______________________________________________<br>
> Toybox mailing list<br>
> <a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
> <a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
<br></blockquote></div><br><br></div><div class="gmail_extra">The biggest problems are:<br></div><div class="gmail_extra">1. Making the code compatible to use with LLVM and CLang which means rewriting and not patching.<br>
</div><div class="gmail_extra">2. That Linux compatibility is not necessary. Once "1" is done, then all that's required is to "remap" whichever libraries to their proper places in FreeBSD.<br></div>
<div class="gmail_extra">3. That the BSD type operating systems are not Linux, andthat they are not setup the same way.<br></div><div class="gmail_extra">4. Finally, if any of you actually believe that all systems can work all things the same way, you're going to be in a world of shit because it means you have stopped being able to learn something new.<br>
<br></div><div class="gmail_extra">I'm working on this- along with a few other Linux based programs - but; you are welcome to start your own porting effort. FreeBSD runs on multiple architectures with the Linux compatibility layer only working on i386 and AMD64. NetBSD has Linux compatibility for more architectures. You need to learn about proper branding of elf executables along with porting the necessary libraries if you want it to work through the Linux compat layer.<br>
</div><div class="gmail_extra">OpenBSD does not have any Linux compat nor will it ever.<br></div><div class="gmail_extra">As far as QEmu, Virtual Box, or any of the others are concerned: it is much better and more practical to run a system on bare metal.<br>
</div><div class="gmail_extra">These are my opinions but I did some work with porting VirtualBox and Ardour3 to FreeBSD, so I know what I am talking about.<br><br></div><div class="gmail_extra">Try starting with the Debian-KFreeBSD community first and work from there.<br>
</div></div>