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/


Reply via email to