[Toybox] BSD support

Mon Jan 20 16:55:31 PST 2014

On Mon, Jan 20, 2014 at 10:01 AM, Zack Breckenridge <zbrdge at gmail.com>wrote:

> > 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.
>
> 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).
>
> 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.
>
> > 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
>
> 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.
>
> 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!
>
> Thanks,
>
> Zack
> On Jan 20, 2014 7:37 AM, "Matthew Turk" <matthewturk at gmail.com> wrote:
>
>> Hi Rob,
>>
>> On Mon, Jan 20, 2014 at 9:30 AM, Rob Landley <rob at landley.net> wrote:
>> > On 01/20/14 02:36, ibid.ag at gmail.com wrote:
>> >>
>> >> On Sun, Jan 19, 2014 at 09:25:57PM -0700, Zack Breckenridge wrote:
>> >>>
>> >>> Hello all,
>> >>>
>> >>> I understand that this project is Linux focused, but I can't help but
>> >>> wonder if there would be any positive reception to 'porting' Toybox to
>> >>> FreeBSD (and possibly OS X)?
>> >>>
>> >>> I would like to contribute to the project regardless (these are my
>> >>> three main platforms), and I suppose this could be a much larger
>> >>> undertaking than I'm prepared for. Simply curious. Has this been
>> >>> discussed already and apologies if so.
>> >>>
>> >>
>> >> As I recall, Rob has mentioned the idea of porting it, but ran into
>> >> difficulties getting a QEMU image for testing.
>> >
>> >
>> > I had a thread with Joe Nosay (cc'd). I met Kirk McKusick at Ohio
>> LinuxFest
>> > and told him I couldn't get net, free, or OpenBSD to install under
>> qemu, and
>> > he recommended PCBsd. I got that to install, but the package management
>> > system in the thing doesn't work to install anything not in the base
>> image
>> > (such as mercurial).
>> >
>> > Given that it's not 1997 anymore, I find this somewhat limiting...
>> >
>> >
>> >> So the FreeBSD port should be welcome...if it's done cleanly.
>> >>
>> >> Anyhow, things to watch out for:
>> >> #ifdef __PLATFORM:
>> >> Somewhere, Rob's got a link to "#ifdef considered harmful".
>> >
>> >
>> > It's linked from http://landley.net/toybox/code.html
>> >
>> > There's more advice on http://landley.net/toybox/cleanup.html but that
>> page
>> > is still only half-done...
>> >
>> >
>> >> We try to avoid #ifdef because it obscures the bigger picture, and
>> >> when it's needed, we try to isolate it (better to have one header full
>> >> of ifdefs than a dozen files...)
>> >>
>> >> Non-portable includes:
>> >> These should _never_ go in toys.h.
>> >> I suspect this might mean adding "toy-platform.h" or something similar.
>> >>
>> >> Non-portable functions:
>> >> I think there's some sort of probing that the toybox build system
>> does...
>> >> See lib/portability.c for how we handle some missing functionality.
>> >>
>> >> "Portable" is more-or-less "That portion of POSIX 2008 that is widely
>> >> implemented", afaict.
>> >
>> >
>> > I'm using Posix, LSB, the Linux man pages, and actual testing against
>> other
>> > implementations (especially trying to build linux from scratch).
>> >
>> > Posix is the only one where I need a good excuse _not_ to do what it
>> says
>> > (preferably including a comment in the command implementation that we've
>> > deviated, such as the one in toys/posix/who.c). LSB and the man pages
>> are
>> > advisory.
>> >
>> >
>> >> Also, be sure to check whether it makes sense to use a command on the
>> >> kernel you are porting to. pivot_root may well be irrelevant for you.
>> >
>> >
>> > 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
>> .  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.
>>
>> The long and the short, though, is that Toybox is pretty great and was
>> quite nice to get running in that environment.
>>
>> -Matt
>>
>> >
>> > Rob
>> >
>> > _______________________________________________
>> > Toybox mailing list
>> > Toybox at lists.landley.net
>> > http://lists.landley.net/listinfo.cgi/toybox-landley.net
>> _______________________________________________
>> Toybox mailing list
>> Toybox at lists.landley.net
>> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>>
>
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
>

The biggest problems are:
1. Making the code compatible to use with LLVM and CLang which means
rewriting and not patching.
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.
3. That the BSD type operating systems are not Linux, andthat they are not
setup the same way.
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.

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.
OpenBSD does not have any Linux compat nor will it ever.
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.
These are my opinions but I did some work with porting VirtualBox and
Ardour3 to FreeBSD, so I know what I am talking about.

Try starting with the Debian-KFreeBSD community first and work from there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20140120/b2bdbcca/attachment-0002.htm>