Fair enough. I can't think of a better way, either. On Aug 27, 2012, at 11:30 AM, Brice Goglin wrote:
> Yes it's an internal output state (which XML document/file are we > writing to, which XML node are we currently setting up, ...). Hiding > inside the topology would cause problems if multiple threads export at > the same time :) > > I thought about renaming it from "reserved" to "private_context" or so, > but we're already talking about exporting "application-private" data, so > talking about another "private" wasn't a lot more clear :) > > Brice > > > > Le 27/08/2012 17:26, Jeff Squyres a écrit : >> Looks good. >> >> My only comment is that it seems a little odd to pass the "reserved" context >> through. Is that some internal XML state? Can that be hidden somewhere >> else, on the topo or the obj? >> >> But that's a minor quibble. >> >> >> On Aug 26, 2012, at 5:52 AM, Brice Goglin wrote: >> >>> (breaking the thread since we're far from valarrays now). >>> >>> I've played with this idea and came with the attached interface change. >>> Aside from low-level backend changes, everything was very easy to implement. >>> >>> Let's take an example. I modified lstopo to add some userdata to the >>> root object and define the following export callback: >>> >>> static void export(void *reserved, hwloc_topology_t topo, hwloc_obj_t obj) >>> { >>> /* we export random stuff instead of the actual userdata content */ >>> hwloc_export_obj_userdata(reserved, topo, obj, NULL, "coincoin", 8); /* no >>> name */ >>> hwloc_export_obj_userdata(reserved, topo, obj, "MyName", "foobar", 6); >>> hwloc_export_obj_userdata(reserved, topo, obj, "MyValue", "foobarbarbar", >>> 10); /* truncated to 10 chars */ >>> } >>> >>> >>> This callback is only called for the root object since others have >>> userdata=NULL. It exports three lines to XML: >>> >>> <userdata length="8">coincoin</userdata> >>> <userdata name="MyName" length="6">foobar</userdata> >>> <userdata name="MyValue" length="10">foobarbarb</userdata> >>> >>> >>> The idea behind multiple userdata lines per object is that it helps the >>> application structure its userdata without having to create a single >>> contigous buffer. >>> >>> When you import this with an import() callback, you get three >>> invocations of the callback: >>> >>> ##### name (null) value coincoin length 8 >>> ##### name MyName value foobar length 6 >>> ##### name MyValue value foobarbarb length 10 >>> >>> >>> The optional "name" attribute lets the application recognize things (but >>> they always looked in-order in my testing). >>> >>> My user that wants valarrays would likely export: >>> * the number of elements in his arrays as a first line >>> * the content of his latency array as a second line >>> * the content of his bandwidth array as a third line >>> >>> We set import() and export() callbacks with two different function >>> because it makes the doc much more clear and the requirements are >>> different (import() must be set before load(), export() must use >>> export_userdata()). >>> >>> I am satisfied with all this, I don't have any concern with the >>> genericity of the interface anymore. >>> >>> >>> Now, I still think we should offer some optional basic encoding >>> capability since many users have no clue about XDR or base64. For >>> instance, add export_userdata_encoded() on the side of >>> export_userdata(). On the import side, we could let the application >>> decode with a dedicated hwloc function. But I think I would rather mark >>> the XML line as "encoded" so that hwloc transparently decodes before >>> passing the data to the import() callback. >>> >>> Brice >>> >>> <userdata.patch>_______________________________________________ >>> hwloc-devel mailing list >>> hwloc-de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel >> > > _______________________________________________ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/