Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] merging the valarray branch (with a better name)
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-08-25 07:05:28

On Aug 24, 2012, at 6:52 PM, Brice Goglin wrote:

> * hwloc_set_topology_userdata_blob_callbacks(topology, exportcb, importcb)
> * On XML export, hwloc calls export(obj, &buffer, &len), the application
> callback allocates a contigous buffer if needed, put stuff in there,
> returns it, and we store buffer/len in XML, and we free the buffer if
> needed (force the application to always allocate? or add a callback flag
> to know whether we have to free or not?)

That sounds generally reasonable to me. I think it would be fine to have the exportcb do the allocation and return it. I assume you're asking about allocating vs., say, having something like "static char my_xml_export[1024]", or something like that, right?

If so, I say: keep it simply. Just always allocate/free.

> * On XML import, we read the XML stuff and call import(obj, buffer,
> len). The application would usually read the blob and store it back in
> the object. We'll have to document that the topology isn't ready for
> consulting there yet (or queue callbacks to the end of the XML parsing).

Sounds right.

> We'd likely use something like base64 to encode these blobs so that the
> minimalistic parser doesn't get lost (it doesn't like unusual characters).

I think we should leave it up to the callback to decide -- they could hand us back plain ASCII XML, after all (it doesn't have to be a binary blob). I think we just document the range of characters that we allow to come back in the buffer during the export/allow during the import.

Jeff Squyres
For corporate legal information go to: