On Sat, Apr 23, 2016 at 11:53 PM, Isaac Dunham <[email protected]> wrote: > On Sat, Apr 23, 2016 at 09:57:12AM -0700, enh wrote: >> On Sat, Apr 23, 2016 at 3:06 AM, Rob Landley <[email protected]> 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
