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", 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).
> 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.
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/