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

[enh]

On Mon, Aug 1, 2022 at 3:20 PM Rob Landley <rob at landley.net> wrote:
>
> 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. :)

i'm reliably informed by people who watch a lot more youtube than i
that "regular uploads" and "convenient upload lengths" are the two
keys to making viewers happy :-)

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

yeah, i merged that this morning and haven't heard anything yet ... i
was confused to wake up to breakages _before_ i'd hit submit, but that
seems to be some kernel module change!

> > 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"

yeah, i think the Android Common Kernel (ACK) build is an "extended
subset" of regular kernel builds. but, yes, i was talking about things
that are actually _missing_ for them rather than "it's in pending but
works fine for us already".

> (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