[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH 1/1] target-ppc: Support rtas_get_sysparm(PROCESSO

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH 1/1] target-ppc: Support rtas_get_sysparm(PROCESSOR_MODULE_INFO)
Date: Sat, 31 Oct 2015 10:32:13 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/31/2015 03:33 AM, Sukadev Bhattiprolu wrote:
Alexey Kardashevskiy address@hidden wrote:

Thanks for the review. Agree with your other comments and will address

| >+#include <string.h>
| >+#include <errno.h>
| >+
| >+/*
| >+ * TODO: <fts.h> doesn't like __USE_FILE_OFFSET64 but hopefully we don't
| That's ugly :-/ Google is saying there is
| http://linux.die.net/man/3/ftw which looks newer => better.

Like I say below...

| >+ *     need to deal with large file offsets in /proc/device-tree. If we
| >+ *     must, we should fall back to walking the tree with opendir().
| >+ *     Another alternative is nftw() but that requires us to use global
| >+ *     variables to keep the counts of chips/cores etc so we need to
| >+ *     serialize access to the globals.
| >+ */

for each file, nftw() calls the 'fn()' parameter but there is no state
info saved from one call to next. So if we find a chip and want to increment
a counter, we need a global variable and some serialization. I was trying
to keep it simple, given that device-tree files we care about are not large.
But should we add a mutex and increment global counts instead?

I do not really understand why you need to walk the whole tree while the nodes you are interested in are just these:


These are known locations which are unlike to change.

btw why do you double-check for PowerPC,address@hidden/device-type to have "cpu"? Can it be something different? On what system?

And what is "ibm,hw-module-id"? None of my systems has it - Tuleta, Firestone. Is that NUMA?

Another thought - all CPUs can be enumerated via /sys/devices/system/cpu/cpu* and nodes - via /sys/devices/system/nodes, they all have symlinks to each other and to the device tree, might be useful for this task, not sure though.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]