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