https://landley.net/notes.html#23-07-2022 said: > In toybox, I keep breaking stuff that's in "pending", which wouldn't be a > problem except Android USES stuff out of pending. Next release is scheduled > for the 6th (3 months since last time), but the release AFTER that I should > prioritize trying to promote all the commands Google uses out of pending. > > Let's see, Android.bp says: > > all_srcs: dd, diff, expr, getopt, tr > device_srcs: brctl, getfattr, lsof, modprobe, more, stty, traceroute, vi > > Hmmm. I'm working on the first two of those already. Where's the list > Ellliott sent me a while back... > > priorities: > dd > diff (--line-format, -I) > expr (GNU unary +) > getopt > ! hexdump (-n#, -s#, -C, -e, -f FILE, -v) > realpath (-s (--no-symlinks), --relative-to) > tar (--transform) > tr > > less important, just used for debugging buildbot issues: > ! fuser (no flags, explicit filename, -v, -k) > lsof > ! pstree (-pal for ninja, -A for ltp) > > Which mostly overlaps the above two (and adds features to non-pending stuff), > so the third batch of commands would be: > > enh_srcs: hexdump, realpath, tar, fuser, pstree. > > Which isn't "fish these out of pending" just "todo this year". Most of > Elliott's list is already in those first two, although it also adds features > to non-pending stuff. > > 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. 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) for kernel. (i'm calling `tar --transform` and `tar --null` "done" until/unless proven otherwise, since i think they're "done enough".) "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 :-) ) _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
