Jeff Squyres wrote:
>> * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new
>> hwloc_topology_t parameter. The problematic ones are:
>> + int hwloc_plpa_sched_getaffinity(pid_t pid, hwloc_cpuset_t cpuset);
> Hmm. I'm a little confused. If we don't provide a drop-in PLPA
> replacement API implementation, what's the point of implementing a
> PLPA-like API? PLPA users will still need to modify their code --
> shouldn't we be pointing them to the more-powerful hwloc API instead?
> There's certainly some desirable PLPA API features that could be
> imported to the HWLOC API -- but I would think that if people want to
> keep using the PLPA API, they can. It just won't [ever] be updated.
> The existing (and future) hwloc API is the migration path forward --
> I'm not convinced that providing a new API that's halfway between PLPA
> and hwloc is worthwhile...
Agreed, let's just remove this and tell people to use hwloc_[sg]et_*cpubind.