[Toybox] [PATCH] Another Android roadmap update.

[enh]

On Sat, Aug 15, 2015 at 7:41 AM, Rob Landley <rob at landley.net> wrote:
> On 08/14/2015 07:51 PM, enh wrote:
>> while i'm on the subject, here's a quick braindump of the status of
>> the things still on the list:
>>
>> dd
>> -- currently using NetBSD dd, so in no rush here.
>
> Which puts that command back in "I've gotta do a better job or there's
> no point" territory. :)
>
>> du
>> df
>> -- need to finish the humanize_number work.
>
> I'll take my lead from you on this one.

with this weekend's patches, i think i could try flipping the switch
on these. i might need to fix df's column sizing first though ---
Android's filesystems tend to have much longer names than Ubuntu ones,
and the hard-coded 16 characters isn't enough.

>> iftop
>> ioctl
>> lsof
>> prlimit
>> -- will rewrite these at some point. turns out there's an existing
>> prlimit with a much friendlier command-line than ours
>> (http://man7.org/linux/man-pages/man1/prlimit.1.html).
>
> I have part of an lsof here I could take a stab at finishing. The
> problem is the lsof man page is 2700 lines long and I dunno what a sane
> subset of this would be. (Suggestions and/or test cases welcome...)

yeah, this is one reason i haven't tried to upstream the Android lsof
yet either --- it's a tiny fraction of "real" lsof.

> The ioctl command hasn't got a man page in ubuntu, and when I type it at
> the command line it doesn't even suggest a package to install.
> Unfortunately, my macbuntu image hasn't got aosp installed on it, and
> when I tried to follow the instructions apt-get prompted me to uninstall
> various 64 bit packages so it could install the 32 bit versions. When I
> tried to install it in a fresh VM last weekend it ran out of space (30
> gigs is not enough for Ubuntu+AOSP, apparently) so I need to install
> another fresh VM image with more space and try again...
>
> I've lumped iftop in with top, iotop, and a second pass at vmstat. Ala
> "there's probably some shared infrastructure here, but I'm not sure
> exactly what yet."

i wouldn't be surprised if no one's run iftop since it was checked in.
i'm tempted to remove it and see if anyone notices, especially because
our iftop isn't much like the real iftop; it's more of a ping-style UI
than a top-style one.

> It's also shared with less, and the draw_tail() stuff in hexedit.c for
> doing utf8 fontmetrics on strings needs to be genericized into
> lib/interestingtimes.c and then I need to figure out a callback
> infrastructure to escape unprintable characters since that's not done
> consistently between contexts. And then "watch" needs to get its output
> washed through that too... (I.E. doing this right means utf8 support
> from day one...)
>
> (Sigh. I haven't even done the cleanup pass to get the various manual
> tcsetattr() calls using set_terminal() where appropriate.)
>
>> ls
>> -- making progress on the adb/CTS side of things. hopeful we can flip
>> the switch this month.
>
> Let me know if I need to fix anything else there. (The strwidth() in
> there might need to get pulled into the above general fontmetrics stuff,
> but for the moment it should work as-is and handle utf8 names.)

no, other than the user/group mixup and the missing -h (which toolbox
didn't have either, but people have explicitly said is one of the
things they're looking forward to from toybox), i'm not aware of any
problems on the toybox side.

>> log
>> nandread
>> newfs_msdos
>> uptime
>> -- ???
>
> I think uptime's good? (Matches ubuntu, anyway.)

it doesn't match Android's traditional uptime output, though, and i
don't know if anyone cares. this might be a case where i should
experiment to find out.

> mkfs.vfat isn't that big of a todo item, I should just do it. (It's got
> some strange corner cases but I think I have them all listed now. I'm
> _tempted_ to do mtools, and a mke2fs/mksquashfs/mkisofs equivalent for
> vfat, which is where it all turns into a Big Thing and gets shelved
> again, but I can do that later.)
>
>> ps
>> -- toybox ps still needs a lot of work, so i'm not even looking at this yet.
>
> Yeah, I got distracted from that halfway through by one of the japan
> trips, I should get back to it...
>
>> start
>> stop
>> -- probably make more sense as shell scripts
>
> Ah, initctl. That's part of the init can of worms, and I don't expect
> toybox to replace android's init any time soon. Shell script sounds fine
> to me for your needs. :)
>
>> top
>> -- a few options used in Android bug reports to implement.
>
> I have _no_ idea how to do a test suite for this one, and without
> regression tests I'm reluctant to touch it.
>
> That said, signal.h and poll.h are both included from toys.h, command
> line options should go before interactive stuff in the help text for
> consistency, the interactive keys in Ubuntu's top are case sensitive, it
> has three different open()/read(toybuf)/close() (which could all be
> readfile() anyway, which it _does_ use elsewhere...)

for interactive use, i think the toybox top is already ahead of the
toolbox one. it's the bugreport use case i'm thinking of.

> Ok, yeah, I should poke at that some...
>
> Meanwhile the set of things I'm attacking right now are mostly in the
> status page's "development" target:
>
> http://landley.net/toybox/status.html#development
>
> That's so I can replace the rest of busybox in aboriginal linux. (It's
> what I've got a real world data regression test harness for.)
>
> Once I've got that building linux from scratch without busybox, my
> _next_ target is to try to get it building AOSP. Which is likely to be
> _so_ much fun. (On the bright side, a panel I attended at Linuxcon Japan
> may have given me enough info to write a git tool capable of satisfying
> repo's needs, although it's still a big command to write and the first
> pass would be download-only. Still, one more chunk of a self-hosting
> build environment...)
>
> Actually before I do _that_ I need to tackle the libc can of worms
> (migrate aboriginal off of uClibc to musl for the supported targets,
> which is currently blocked by my Linux From Scratch 6.8 regression test
> having more than one package with an if/else staircase of libcs it
> recognizes with an #error at the end), and then extract bionic from the
> AOSP build (nontrivial) and see if I can build aboriginal with that and
> how the native build environment behaves under it (probably not pretty)...

gdb, python, and vim built with bionic all run fine on the target. all
devices >= honeycomb have llvm, and someone at work has run clang on
the device. i don't don't if anyone's built git or make for the
target, but .

> Working on it,
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1439752562.0