Jeff Squyres wrote: > On Nov 12, 2009, at 9:25 AM, Samuel Thibault wrote: > >> > > 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. >> >> What do you mean by "this"? The whole plpa.h or just >> hwloc_plpa_sched_getaffinity? >> > > > My $0.02 / 0.01EUR: let's not try to emulate the PLPA API at all > (i.e., no hwloc_plpa_* functions). Let's just take any good ideas > that were there and incorporate them into the future of the hwloc API > as appropriate.
Well, the list of good ideas will be very short then :) Most remaining functions are about manipulating core and socket ids, we don't need that at all in hwloc anymore. My feeling is that converting an application from PLPA's core_id/socket_id API into the hwloc API will be non-trivial. So at least the current hwloc_plpa_* functions will be document a bit how to switch to the hwloc API. Brice
