On 04/14/2013 11:56 PM, Alan Robertson wrote:
> I see that you faithfully replicated one of my screwups ;-)
>
> I shouldn't have included memory under a CPU, but outside of the cpu
> data... Sigh... [Not your fault]
But at least I removed HugePages since they don't exist on 32-but ARM :-)
I know what you mean though. Memory may need to be a whole separate
agent at some point as there may be different points of interest to pick
out of /proc/meminfo on different architectures.
>
> This is going to have to wait until release 0.2.0 - it's just a
> question of timing. Sorry!
>
> But I do appreciate it!
>
> We should discuss how this really ought to be formatted in general on
> the mailing list, then specifically for each of the various CPU
> types. But the overall format (like being multi-processor-friendly)
> should not change. And my screwup of slamming the memory in with
> the last CPU should not be repeated (and should be corrected).
I was going to look around and see if I can find samples from
/proc/[cpuinfo,meminfo] on all the other architectures to get a better
idea of what the format should look like.
>
>
> The point of the format is to try and make as much harmony out of the
> dissonance out there as we can. And, eventually, the format won't
> have to change when people start making multi-socket ARM boards (or
> multi-core ARM chips).
Oh, they are out there... plenty of Android devices are multi-core ARM :-)
>
> On 4/14/2013 9:21 PM, Brian Tinsley wrote:
>> Attached is a (very) preliminary patch for extending the "cpu"
>> discovery agent to support non-x86 processors, specifically 32-bit
>> ARM systems in this case...and single CPU systems to be even more
>> specific. Example output is:
>>
>> {
>> "discovertype": "cpu",
>> "description": "CPU information",
>> "host": "apc-apricot",
>> "source": "./cpu",
>> "data": {
>> "ARMv6-compatible processor rev 7 (v6l)": {
>> "BogoMIPS": 532.24,
>> "Features":
>> {"swp":true,"half":true,"thumb":true,"fastmult":true,"vfp":true,"edsp":true,"java":true},
>> "CPU implementer": "0x41",
>> "CPU architecture": 7,
>> "CPU variant": "0x0",
>> "CPU part": "0xb76",
>> "CPU revision": 7,
>> "Hardware": "WMT",
>> "Revision": 0000,
>> "Serial": 0000000000000000,
>> "MemTotal": 461604
>> }
>> }
>> }
>>
>> The patch also provides a framework for supporting even more CPU
>> architectures. Output of the "uname -m" command drives this and the
>> text matching was largely gleaned from a few automake "configure"
>> scripts.
>>
>> Processors that don't have a parser for the CPU data currently just
>> return the output of "uname -m" and the string "unsupported" for now:
>>
>> {
>> "discovertype": "cpu",
>> "description": "CPU information",
>> "host": "not-really-an-irix",
>> "source": "./cpu",
>> "data": {
>> "mips": "unsupported"
>> }
>> }
>>
>> Let me know what you think! Just be kind... I'm knocking off the rust
>> as I go along here :-)
> I'm not a fan of harsh mailing lists. I know they're really common,
> but I don't care for them (they seem childish), and if I screw up and
> am harsh without blindingly obvious reasons, feel free to let me know.
>
>
>
> -- Alan Robertson
> [email protected]
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
