On Mon, Aug 1, 2022 at 3:20 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
