On Tue, Dec 2, 2014 at 2:09 PM, Rob Landley <[email protected]> wrote: > On 11/25/14 21:14, enh wrote: >> actually, loop_max =1 gives the right behavior by accident (because of >> the break in the loop), so setting loop_max = 0 is a better idea. > > Sorry for the delay in replying. I'm hip-deep in deflate > compression-side logic (implementing the rest of gzip, somebody poked me > and said they need it now), and the vmstat command is a can of worms for me. > > My most recent cleanup pass on vmstat was: > > http://lists.landley.net/pipermail/toybox-landley.net/2013-December/001513.html > > And that description ends with the fact that I have no CLUE how several > of those fields are calculated. What we're doing doesn't match what > other implementations are doing, and there's no standard or > documentation on what it _should_ be. (Trying to find that sort of thing > out is a giant timesink. Gotta do it eventually, but there are higher > priority todo items at present, at least until somebody pokes me and > says "I need X now". :) > > Yes, there are some "pending" commands that aren't in the "pending" > directory, the list of them is in toys/pending/README. Initially I just > had a list of commands needing cleanup, but it kept getting longer as > contributions came in faster than I could clean them up, and I added > toys/pending when the list got too long to manage. I've got it down to > 11 commands and one lib file, and I keep meaning to just properly review > and clean up that old list rather than try to explain it to people, but > the remaining issues in those commands tend to be nontrivial (or I'd > have fixed them by now). Sometimes, simple is a destination you go > through a lot of complexity to reach... > > Anyway, your bug is easy to test and thus easy to fix, but I'd actually > fix it in a different way because: > > 1) I'm uncomfortable assuming INT_MAX will never be reached. (Yeah, > almost certainly true in this case but INT_MAX != infinity and I don't > want to get into the habit.) > > 2) Minor bug with "./vmstat 2 3" where it has the 2 second pause right > before exiting. It'snot going to produce more output, so it should just > have the pause twice. > > Did the fix I just checked in work for you?
in the sense of making the command-line arguments behave, yes, this works fine. as for the "what are these fields and what should they mean?", yeah, i was leaving that for later. Android's vmstat does look a little different and "toolbox vmstat" and "toybox vmstat" don't produce the same output, even for the fields they share (like 'in'): /huge-ssd/aosp-arm64/bionic$ adb shell toolbox vmstat procs memory system cpu r b free mapped anon slab in cs flt us ni sy id wa ir 0 0 1172960 12660 13336 36532 113 204 0 0 0 0 99 0 0 /huge-ssd/aosp-arm64/bionic$ adb shell toybox vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 1173364 4316 345556 0 0 43 28 0 234 1 1 98 0 i don't know what i'm going to do about that, but wanted to at least get easy stuff sorted out first. i'm likely to have a lot of trouble with commands where the output is different even if it's clearly better (like ifconfig) because i don't know what (if anything) is trying to parse the existing output. > Rob > > (Sorry, I ramble a bit when sleep deprived. #include Henry David > Thoreau's apology for writing a 5 page letter because he didn't have > time to write a 1 page one...) _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
