I propose the following changes to the object attributes. struct
hwloc_obj now contains a struct hwloc_memory pointer:
struct hwloc_memory {
unsigned long total_kB; /* Total memory in this object and its children */
unsigned long local_kB; /* Local memory in this object */
struct hwloc_memory_pages {
unsigned long size;
unsigned long count;
} * local_pages; /* 0-terminated array of pages or hugepages sizes and counts
*/
}
This obj->memory could be NULL except for Node, Machine and maybe
System. Cache attributes are still specifically in
obj->attr.cache.{size,depth} since they are different from the above
semantics.
> I'd say it can be valuable to support key=value pairs on any object so
> that future object types can be extensible (e.g., vendor pci devices).
> But common stuff should be accessible as struct members so that
> there's no string parsing needed (I'm no doubt just voicing what we
> all already think). I.e., esoteric stuff can start as a key=value
> strings but as they get mature / popular, they can "graduate" to
> become a struct member.
>
If we do the above, Node and System won't have any specific attribute
anymore. Machine will still have DMI infos. But I am not sure they are
common enough and deserve an actual struct field, they could stay in the
array of stringified info.
Actually, maybe obj->name should go there as well before it mixes to
many meanings. It's mostly unused in trunk, except to store "Kerrighed"
since very recently. We talked about using it to store the hostname of
Machine objects. And the libpci branch uses it to store the PCI
vendor/model string and OS device names. Maybe all these shouldn't be in
obj->name and rather in the array of strings as OSName=Kerrighed,
Hostname=foobar, PCIVendor=foo, PCIModel=bar, OSDevice=eth2, ...
Brice
