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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
