[Toybox] another way of thinking about https://landley.net/notes.html#23-07-2022

[Rob Landley]

On 8/1/22 15:39, enh via Toybox wrote:
>> So the collated Android TODO list would be: dd, diff, expr, getopt, tr, brctl, getfattr, lsof, modprobe, more, stty, traceroute, vi, hexdump, realpath, tar, fuser, pstree.
> 
> i think another way to think about this (which may or may not be
> helpful) is to think of three different targets: AOSP vs kernel vs
> NDK.

I just spent the weekend and then some trying to get back into the swing of
video recording, so I'm not sure what my prioritization looks like right now. :)

(Although partly that was trying not to break anything new in case another
bugfix came in from your resync. :)

> AOSP is, i think, the one you think about the most (and is probably a
> superset of the others), but for that reason (the "superset" part) i
> wonder whether starting with the kernel isn't a better idea? (in the
> "secret of happiness == achievable goals" sense of "better"). if you
> slice it that way instead, you get "all of the above" for AOSP, but
> just:
> 
>   diff (-I)
>   realpath (--relative-to)

I do kernel building under a toybox-only $PATH with mkroot all the time (that's
what the "airlock" step sets up), although what specifically it needs is very
config dependent (different configs/targets need different commands, powerpc
calls $BASH out of the $PATH for example) and to make it work I had to symlink
this list of commands out of the host $PATH that toybox does not yet provide:

PENDING="dd diff expr git tr vi bash sh xzcat bc ar gzip   less awk unxz bison
flex make nm"

(And that's on top of fudging and enabling toysh and route in the toybox .config
it builds. The double space is the breakpoint between "I've got a start of this
in pending" and "I do not have a start of this in pending".)

Bison and Flex showed up when they made kconfig turing complete and added the
ability for kconfig to call "rm -rf /home" in 2018. I need to finish gzip
compression-side. I honestly don't remember why vi is in there, I should take it
out and see what breaks. I vaguely recall "less" was used as a NOP passthrough
somewhere (when stdout isn't a tty it's basically cat)...

I should do another pass trying to remove each command and add it back when I
know why it's needed. I literally have a patch removing the need for bc but...
(Sigh. Peter Anvin wanted to make sure  when my perl removal patches went in
that you STILL couldn't build with just busybox. I don't know what he has
against it, but gentoo wasn't install it by default, Linux From Scratch wasn't
installing it... He inconvenienced a bunch of other projects, not just mine.
Nothing else really USES bc except his one weird script that I posted both shell
script and C replacements for BEFORE he merged it.)

And I should finish and promote expr. (The thing is, now that I've got the $((
)) shell plumbing, I REALLY want it to use the same stuff, but they have some
fundamentally different user interface ideas and last time I sat down to try to
unify them I wasn't making progress...)

As for git, I think all the build really needs is "git --describe"? (And that's
toybox needing it as much as the kernel, otherwise you always get the release
version out of toys.h)

Part of the reason I was looking at doing "ldd" a while back is nm, readelf,
ar -s, and strip all kinda share the same elf table traversal plumbing and it
seemed a good excuse to genericize it. (The REST of ar is simple, but ar -s is
just... why, posix committee? Why?)

> for kernel. (i'm calling `tar --transform` and `tar --null` "done"
> until/unless proven otherwise, since i think they're "done enough".)

I'm still trying to finish that properly before saturday...

> "what about NDK?", i hear you ask? (if you're not asking "wait,
> someone's trying to build the NDK with toybox too?".) and the answer
> there is basically "dunno". _i_ haven't looked, but one person on the
> NDK team was curious and gave it a go, and that was the source of the
> `diff --line-format` request, iirc. but afaik they haven't looked
> _further_ than that to try to work out what the next problem is likely
> to be. whereas AOSP and the kernel already operate on an allowlist
> basis that means we know exactly what they're using that's not coming
> from toybox. (though we don't, of course, know what new thing the
> upstream kernel will start using.)
> 
> i don't think it really matters, but since _i_ always like achievable
> goals/intermediate milestones, i thought i'd point out the fact that
> the kernel is probably the low-hanging fruit in terms of being able to
> draw a line under something and saying "done!".
> 
> (another motivation for "android common kernel build first" would be
> that there are soc vendors who're actively looking forward to the
> kernel stuff in addition to the internal kernel team... so that's
> probably the most excited audience too :-) )

Very useful. Thanks.

Rob