Hello I am considering removing some features from hwloc since the next major release will be called 2.0 and it deserves major changes :)
If you care about anything below, please speak up: * the "custom" interface and hwloc-assembler tools (for assembling the topology of multiple nodes): nobody ever used it as far as I know, it complicates the code by allowing NULL cpuset at the top of the topology, and we know the design doesn't work (that's why netloc is coming) * kerrighed support (single-system image): planned for removal since 2012, see https://github.com/open-mpi/hwloc/issues/73 I am also considering this change that shouldn't break existing programs: * always create a NUMA node even if the machine isn't NUMA: we currently use a full nodeset for UMA machines without any NUMA object, and that makes the code ugly. If we're going to break the ABI anyway (removing custom will break the ABI), we could break it even more. Other possible more intrusive changes: * don't put I/O objects in "normal" children since it confuses programs consulting the children list. rather place them under a dedicated child pointer special objects such as Misc may go there as well. * replace hwloc_topology_ignore_type_keep_structure() with a flavor that does not create asymmetric topologies. only remove entire levels that don't add any hierarchy. don't remove single objects within levels in case of asymmetric topologies (restricted by cgroup etc). * remove obj->os_level: pretty much unused and undocumented, can go in a string attribute if really useful Changes requested by some users but that I am not sure what to do yet: * stop having 4 cpusets and 3 nodesets per object and just have 1 cpuset and 1 nodeset depending on topology flags (only allowed, or only online, etc). possibly with ways to switch between modes at runtime * stop having a CACHE type + data/instruction/unified + depth, and just have one type for each of them, such as HWLOC_OBJ_CACHE_L1d. the advantage is that you can switch (type) without special-casing the CACHE subtypes. One drawback is that there are many subtypes in existing machines (at least L1[id], L2[idu], L3[idu], L4u). Also the "Group" type still needs special-casing because of multiple nested groups in large NUMA machines. Other things you don't like and never said? Brice
