[Toybox] Android toolbox replacement status

[Rob Landley]

On 06/29/2016 05:36 PM, enh wrote:
> so, in slightly different form to the roadmap and with more detail,
> here's the current status for remaining stuff to do...
> 
> dd
>   -- i don't have any known problems, but i'm assuming it'll get
> rewritten when it moves out of pending, so i wanted to wait until the
> dust settled. if you think the rewrite is sufficiently far out to make
> this a bad plan, let me know and i'll write patches for some of the
> feature requests i have pending (stuff that isn't in the BSD dd
> either).

I actually started rewriting this once, hit the missing comma parsing
infrastructure, and just never got back to it.

Right now I'm in the middle of cleaning up netstat and wget, adding
--dry-run to patch (which involves fixing an option parsing
infrastructure bug I hit), I have pending changes to wc to make it so
"wc -m -c" can do both at once (ubuntu's can!) and figure out how the
whitespace differences can be smoothed over to let "TEST_HOST=1 make
test_wc" actually work...

Oh wow my todo heap is sad. I've got partial changes so netcat server
mode can work right no nommu and grow a udp mode, AND I need to factor
the plumbing out so i can do tcpsrv/udpsrv/inetd with the same
infrastructure. And I need to test if that's doing ipv6 right. I need to
teach cpio to map UIDs so you can store the current user's files as root
when making a cpio, and it depserately needs a way to store xattrs (and
while I"m at it longer than 32 bit timestamps and file lengths, and
nanosecond time...) I need to add -noleaf to find. I have a mess in
date.c that looks like I was inlining chkmktime? I need to have oneit do
a better shutdown (kill *, if anything left 3 seconds later kill -9 *,
sync(), umount -a (reverse order of /proc/mtab), sync(), reboot().),
what is this in mount...

@@ -297,7 +297,7 @@ void mount_main(void)
   // For remount we need _last_ match (in case of overmounts), so traverse
   // in reverse order. (Yes I'm using remount as a boolean for a bit here,
   // the double cast is to get gcc to shut up about it.)
-  remount = (void *)(long)comma_scan(opts, "remount", 1);
+  remount = (void *)(long)comma_scan(opts, "remount", 0);

That change says not to clean the argument out of the string (so opts
will still have "remount" in it afterwards), which yes is kind of
important because it looks like right now MS_REMOUNT isn't getting set
for remounts? How did that ever work...

This is just a random glance at a few of the 46 modified files in my
tree. I need a month by myself to go through these back todo items
without interruptions. Interruptions is how I develop a pile of stuff I
was halfway through doing when I had to stop...

> getevent/sendevent
>   -- getevent/sendevent look like the obvious next thing for me to
> look at, but i wondered what you want to do about
> https://android.googlesource.com/platform/system/core.git/+/master/toolbox/generate-input.h-labels.py
> --- at the moment we take bionic's current uapi input headers at build
> time and generate a bunch of arrays that let us translate back and
> forth between codes and strings. i don't relish the prospect of
> manually maintaining 1000 lines of constants in toybox. (maintaining
> these large lists of kernel constants is the real problem with strace,
> not the actual syscall interception!)

I have a number of scan and generate utilities in scripts already, I'm
not averse to having another one but I am NOT reintroducing python as a
build dependency. :)

But this one has to get deferred (for me) until I get an AOSP test
environment set up on this netbook.

> grep
>   -- toybox missing --color, but as long as  the point where this is
> the only thing left i might just switch us over anyway. until then,
> this isn't hurting anyone.

I'm about halfway through adding --color anyway. That's ANOTHER of the
many, many partial changes in my tree not ready to check in yet. :P

Speaking of which, do you care about the $GREP_COLOR environment
variable? (I hope not, but have a todo item to ask...)

> newfs_msdos
>   -- this seems the most likely candidate to still be around in O.

It's actually not that hard to do, I did about half the research for it
when you suggested it (and adding mtools stuff), and then got distracted
by crisis du jour.

> reboot
>   -- not obvious to me that i can write this without new
> infrastructure or making a big mess of #if __ANDROID__ inside
> reboot.c?

Again, I need an AOSP build/test environment. :(

>   -- as an aside for anyone wondering, there's no good reason this
> isn't in toolbox right now. there *used* to be, back when reboot
> actually did the work and required capabilities, but when it was
> rewritten to just forward to init, no one merged it back into toolbox.

It's  not hard, I've just been swap-thrashing here for a longish while
and development is fragmented. I need to do an epic tab closing pass,
and a lot of it's to the point I have to stare at stuff and go "what was
the intent here again?"

Rob