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. Brice
