Samuel Thibault wrote: > Now, coming to semantic changes: > - The top node of the tree wouldn't necessarily be a system object. > Actually, having always the top object having the system type is not > providing any useful information :)
And having the root object type vary from machine to system or switch provides useful information about what kind of topology we're working on. > - Objects of network trees may not have cpusets defined (Trees obtained > directly from hwloc with defaults parameter would still have cpusets > on every node however). It does not make sense to merge cpusets of > different machines (they will conflict), and things like shifting > cpusets to be able to merge them would probably only bring issues. > That being said, that does not prevent from writing a transparency > plugin that automatically discovers the network topology, shifts > cpusets, and when requested for binding, automatically migrates to > the machine according to the shift, and uses the underlying OS hooks > to perform the binding. My point is that the hwloc combining operation > wouldn't fix cpusets itself and leave them NULL. The caller of the > combining operation will be responsible for that. > By the way, I thought about making cpuset NULL in PCI objects. But it wasn't strictly required there so I just kept using empty cpusets instead of changing everything else to support NULL. Brice