[Toybox] FreeBSD porting, removing bashisms

Rob Landley rob at landley.net
Tue Mar 29 16:54:40 PDT 2016


On Tue, Mar 29, 2016 at 6:38 PM, Ed Maste <emaste at freebsd.org> wrote:
> On 29 March 2016 at 23:01, Rob Landley <rob at landley.net> wrote:
>>
>> There's also a bunch of Linux Standard Base headers #included from
>> toys.h, which bsd may not have. (Most bsds have a linux emulation layer
>> these days, but I don't know how that works in with building stuff
>> natively...)
>
> Yes, it's not used (or available) for native builds -- the syscalls
> and ioctls aren't available in that case. The Linux emulation layer
> would be used when running an unmodified Linux toybox binary. I'm
> happy enough to just avoid building the Linux-specific tools for now.

The Linux Standard Base headers are #included from toys.h, which is
included from everything. We'd have to modify the global infrastructure
to not be Linux if building on a system that can't emulate a Linux build
environment.

There are also a number of places where we know what the Linux
information is, and use that. For example, in ifconfig:

      // Is this an SIOCSI entry?
      if ((off|0xff) == 0x89ff) {

Because those constants have been there since the linux 1.x days, are
target-independent (same on arm/mips/ppc/etc), and can't change or
it would break binary backward compatability with existing userspace
programs (Which Linux hasn't done going back to 0.0.1, modulo
intentionally removed features like devfs).

That's been part of the design all along: this is implementing a
Linux command line.

>> I've intentionally kept bashisms in the scripts because toybox's
>> built-in shell (toysh, currently just a stub) is intended to provide a
>> "reasonable bash replacement". (About the same level of bash extensions
>> beyond posix that our that sed or ls implementations have beyond posix.)
>
> In that case, having a small bash equivalent sounds good to me. What
> do you think about changing #!/bin/bash to #!/usr/bin/env bash then?

Why is expecting /usr/bin/env to be at a specific absolute path less
constraining than expecting bash to be at a specific absolute path?

I've never understood that one...

> diff --git a/scripts/make.sh b/scripts/make.sh
> index d3dc8eb..d09cac0 100755
> --- a/scripts/make.sh
> +++ b/scripts/make.sh
> @@ -1,1 +1,1 @@
> -#!/bin/bash
> +#!/usr/bin/env bash
>
> Another error shows up in a few spots due to conflicts between a
> couple of toybox functions and libc:
>
> ./lib/lib.h:204:7: error: conflicting types for 'strnstr'
> char *strnstr(char *line, char *str);
> ./lib/lib.h:289:7: error: conflicting types for 'basename_r'
> char *basename_r(char *name);

In neither case did you say what the conflicting definition was. What
header they came from, how they're defining those prototypes...

It's a pity we don't have an #undefine for function prototypes in C.

That said, we have lib/portability.c and lib/portability.h to paper over
that sort of issue.

Rob

 1459295680.0


More information about the Toybox mailing list