Brice Goglin, le Thu 07 Mar 2013 23:59:54 +0100, a écrit : > We have a specific ABI field in the main component structure > (hwloc_component) to avoid problems in case we break this new ABI. > Breaking it isn't as bad as breaking the main hwloc ABI, but it'd still > be good to not break it in every major release anyway. If you see > anything to change to make things more future-proof, let me know, I'd > rather change it before v1.7.
I'm wondering about the hwloc_disc_component_type_e values and excludes. AIUI, GLOBAL is supposed to exclude anything else, while CPU excludes with other CPUs, and ADDITIONAL isn't supposed to exclude with anything except GLOBAL. I hope I have made it clearer in the documentation. BTW, it seems we're not supposed to set multiple types in the type field; that might be a concern, I'd tend to see the type field as an OR of types. I'm wondering whether these rules "you should always set GLOBAL in excludes", and "GLOBAL should always set all types" are really nice. For instance, some component built against 1.7 will not include flags that we will introduce in 1.8, etc. So I'd say that GLOBAL should rather be special-cased, by making it ~0, as for now it's a bit confusing that it looks like CPU. ADDITIONAL could be renamed MISC, meaning that it's something that another component should not have to care about. We can for instance document that it does not make sense to exclude MISC, unless through GLOBAL. I'm wondering whether we should already introduce various types for the various additional plugins we already have: OpenCL, PCI, nvml, gl, cuda. I'd tend to reckon it makes sense to, so that third-party can already exclude them from their plugins, if they ever need to (better provide the feature than wait for people to ask for it next century). About extensibility in general, the abi field will indeed allow us to be able to introduce e.g. other callbacks. BTW, is there really a reason for making the next field last in the structure? When we'll add other fields, it'll look odd being in the middle of the structure. Perhaps it's the methods which should go last, as we'll probably introduce methods in the future? Also, shouldn't we already bump the COMPONENT_ABI on 1.7 release? Perhaps it should be put along others in VERSION, so we easily take the same care as the soname? Samuel
