Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] upcoming hwloc v1.7
From: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2013-03-22 14:35:01


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