[Toybox] ps and top (and Android)

[Isaac Dunham]

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.

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.

> > 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