On 10/26/2015 11:25 AM, enh wrote: > bionic had to give up on using /proc/cpuinfo or /proc/stat for > counting cpus. in particular, a certain soc vendor rob's worked for in > the past insists on doing things wrongly. the only methods we've never > had problems with on any kernel on any architecture are: > > if you want online cpus, parse /sys/devices/system/cpu/online. > > if you want offline cpus too, count cpu\d+ entries in /sys/devices/system/cpu. > > is there a reason why you don't just use sysconf(3) and let it be the > C library's problem? (if so, that's probably worth a code comment.)
Switched to sysconf() (I was looking in sysinfo() and going "I thought this was here...?"), and trying to clean up for a release (so I can get an aboriginal release out because -rc7 and being _three_ kernel versions behind would just be sad). I'm intending to promote ps.c, fix a bug I found in patch (a hunk that applies to the start of a file does not apply properly at an offset, although it _think_ it does), and maybe clean up pgrep.c, pkill.c, and test.c. And you'll love this: the test.c in pending segfaults when given no arguments, and the first test is basically: test || echo false Which passes with the segfault, despite your extra plumbing to catch return values >127, because the return value to the script is 1 (from false). So there's that, not sure how to fix it. (Other than just fixing the command.) That said, bash is reporting the segfault through to the command line anyway... Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
