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.