[Toybox] runcon requires CONFIG_TOYBOX_NORECURSE=y

[Rob Landley]

On 01/22/2016 11:25 AM, enh wrote:
>> I'm promoting three of the commands you _are_ using in pending this
>> release cycle. Trying to get ahead on that...
> 
> don't just look at this list:
> 
>     toys/pending/dd.c \
>     toys/pending/expr.c \
>     toys/pending/lsof.c \
>     toys/pending/more.c \
>     toys/pending/netstat.c \
>     toys/pending/route.c \
>     toys/pending/tar.c \
>     toys/pending/tr.c \
>     toys/pending/traceroute.c \
> 
> make sure you look at what we actually link to. dd and traceroute
> still come from BSD and iputils respectively. i may as well stop
> building toybox traceroute because i don't think the kernel networking
> folks have any interest in moving off iputils.

Understood.

My roadmap includes system bootstrapping with a minimum number of
packages (ideally kernel, libc, toybox, toolchain). Building a minimal
system you can then build more packages under.

It's Android decision of the want to use other packages' version of some
of those tools, but I still need to provide the complete toolset in that
use case. If I'm cross compiling to bootstrap a new target (j-core and
hexagon and so on), I need the tools necessary to natively compile the
tools on target (under an emulator or on prototype boards) to break the
chicken and egg problem of system bootstrapping.

Traceroute is in there because it was contributed, and because it's
useful on minimal routers and such, and there's a certain amount of
pressure towards feature parity with busybox, but it's not central to
toybox's goals the way "dd" and "grep" are. Building one natively after
a minimal development environment is up isn't a big deal. (That said,
once ping is in, traceroute's well over halfway done.)

> actually, the "two layers of pending" is more interesting than that...
> you don't consider grep pending, for example, but my notes have both
> missing features on your side, and C library stuff for me to
> investigate on our side:
> 
>    grep --- missing -A, -B, -C, color.

Yeah, I have that in my todo list here. (As is some backref stuff for
parenthetical matching, Izabera on irc was getting me some test cases
for that.)

Grep got to a good stopping point, but it was incomplete, and turned out
to be relying on some glibc extensions that I since ripped out.

I'm working as fast as I can but there's so much to do...

> compare performance with BSD
> grep before switching; BSD grep has work arounds for performance in
> the BSD regex implementation.

So does gnu grep, according to a post I read it basically mmaps the
entire file and runs regex against the whole thing when it can. I can
implement something like that, but correct behavior's come before
performance so far.

(I tried to work out a design using fixed size block reads but no fixed
size is guaranteed to hold an entire line, and if a regex match crosses
a line boundary how do you know where it would have started? Basically
have to back up to the start of the previous line, which may not be in
the block...)

Oh, and it should work with embedded NUL bytes so you can grep binaries...

(Often when I'm not picking at something right now it's because to do it
RIGHT is a larger and more elaborate tasks than is immediately obvious.
See ps and the ongoing top rewrite...)

> but dd and grep are low priorities on our side because we've long had
> high-quality implementations of those anyway.

Indeed. I hope to eventually offer better versions, but I don't yet.

I don't recommend using worse code just because it's toybox. I welcome
feedback to help improve toybox, but A) I realize that sort of
evaluation is significant work on other peoples' part they're not
obligated to give me, B) my todo list is already full of massive piles
of stuff I already know I need to do, C) displacing "good enough" is
really hard and migrating has its own cost.

So I'm just doing the best I can as fast as I can...

> ps is the
> highest-profile tool that still needs replacement.

I'm pretty happy with the current state of ps; the file's still changing
because of top and because I'm factoring out common code to move to
lib/, but the one in the upcoming release should be worth evaluating.

Rob

 1453527487.0