[Toybox] ps and top (and Android)

[enh]

On Sat, Apr 23, 2016 at 11:53 PM, Isaac Dunham <ibid.ag at gmail.com> wrote:
> On Sat, Apr 23, 2016 at 09:57:12AM -0700, enh wrote:
>> On Sat, Apr 23, 2016 at 3:06 AM, Rob Landley <rob at landley.net> wrote:
>> > Non-pending commands _not_ included in the build:
>> >
>> > $ make list_working | tr ' ' "\n" | \
>> >   egrep -v "^($(./toybox | tr '\n ' '||'))\$" | xargs
>> >
>> > $ make list_working | tr ' ' "\n" | \
>> >   egrep -v "^($(./toybox | tr '\n ' '||'))\$" | xargs
>> > catv chvt count eject factor fstype fsync halt hello hexedit hostid
>> > iotop killall5 link login lspci mix mkpasswd nfsmount nproc nsenter
>> > oneit passwd poweroff readahead reboot reset shred skeleton
>> > skeleton_alias su switch_root test_many_options unlink unshare uudecode
>> > uuencode w who
>> >
>> > what have we skipped:
>> >
>> > You have your own init/login and toybox hasn't completed that circle yet
>> > anyway (halt/oneit/poweroff/reboot/reset/switch_root/killall5), you
>> > don't use standard uids (login/mkpasswd/passwd/su/w/who), no vga ttys
>> > (chvt), I should filter the examples directory out of "list_working"
>> > (hello/skeleton/skeleton_alias/test_many_options), nfsmount is just a
>> > todo item in mount (it needs a command that can prompt for password),
>> > and you have your own non-oss audio layer (mix).
>> >
>> > We can also say that count/factor aren't important, blkid covers fstype,
>> > sync covers fsync (albeit less efficiently, and I'm trying to remember
>> > if the "fsync /dev/sdb" to flush pending I/O to a specific block device
>> > is actually supported upstream or was an out of tree patch...), and you
>> > have the standard cat -v (catv).
>> >
>> > That leaves:
>> >
>> > eject hexedit hostid iotop link lspci nproc nsenter readahead shred
>> > unlink unshare uudecode uuencode
>> >
>> > The four that jump out at me are link, unlink, uuencode, and uudecode,
>> > which are in posix. I'm aware ln and rm cover the first two, and base64
>> > more or less covers the rest, and yet:
>> >
>> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/link.html
>> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/unlink.html
>> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uuencode.html
>> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uudecode.html
>>
>> it turns out no-one born later than about 1985 has even heard of
>> uuencode/uudecode. it has to be explained as "a historic form of
>> base64". yagni. (bionic also doesn't have the posix a64l/l64a for
>> similar reasons, although the fact that they explicitly operate on a
>> static buffer is the biggest nail in their coffin.)
>>
>> link/unlink was a surprise to even the old-timers, and seem to offer
>> nothing other than confusion beyond the well-known ln/rm. yagni.
>
> IIRC, I heard that unlink was intended to avoid the need to sanity-check
> and escape file names:
> to delete a file named '-h' or '-f', just run 'unlink -h'/'unlink -f'.
> Of course, GNU mis-implemented it, so it's useless if it's compatible.

if that was the intention, it's useless anyway, given the
posix-specified -- for all argument parsing.

(that they added this so late just makes it even more stupid. but
that's about what you'd expect from posix...)

> link, I can't tell, unless it was the same logic.
> It's from Issue 5 (Unix 98).
>
>> > iotop: If the android kernel doesn't have CONFIG_IRQ_TIME_ACCOUNTING
>> > enabled, this won't do you a whole lot of good. :)
>> >
>> > lspci: most android devices don't have pci busses, but android gets used
>> > in the embedded space sometimes... *shrug* (I worked on one that did in
>> > 2012, but the product was doomedish and the company recently got acquired.)
>>
>> what we really don't have is /usr/share/misc/pci.ids.
> See:
> http://pci-ids.ucw.cz/v2.2/pci.ids
> http://pciids.sourceforge.net/v2.2/pci.ids
> (Optionally add .gz/.bz2 for the compressed version.)
>
> Dual license, GPL2+ or 3-clause BSD.

what i meant is "folks would notice if i shipped an extra megabyte of
useless data". even the half megabyte of usb ids, which would be
somewhat useful, seems excessive.

>> > nproc: prints number of CPUs. Might be useful, and is in modern
>> > coreutils, but you can get the info out of /proc or /sys if you need to.
>>
>> "what does number of CPUs mean?" is one of the most popular Android
>> questions. nproc only gives one of the possible answers, so probably
>> more harmful than useful.
>>
>> > nsenter/unshare: Someday, opening the containers can of worms would be a
>> > really nice thing for Android to do. But we've talked about how there's
>> > Much Design Work to do to make that happen. Still, if the kernel
>> > plumbing's enabled, maybe for O?
>> >
>> > readahead: was requested. Seems like a redhat-ism to me.
>>
>> for the most part i took the view of "if it's not in the base goobuntu
>> install, no one cares". (not foolproof, because what's useful on a
>> developer's workstation and what's useful on Android aren't
>> necessarily the same, but it's a reasonable place to start.)
>>
>
> When I bothered with things like that (for example, to give Firefox a
> faster cold start, back when I still thought Firefox worth using), I
> just cheated and did cat ... >/dev/null.
>
> What I've heard gave me the impression that readahead is most relevant
> for perfomance on hard drives (spinning rust), but it *might* pertain
> to slow solid state things like SD cards.
>
> Thanks,
> Isaac Dunham



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