hwloc_obj_t already has a "void *userdata" for this. But we cannot store
it in XML unless we know what it contains.
Exporting to XML is strictly required here since people want to add
values to the XML topology in a preliminary benchmarking programs, and
later read it back in their actual application (a charm++ scheduler).
Brice
Le 24/08/2012 15:00, George Bosilca a écrit :
> If the goal is to allow extra storage for the users why not a simpler
> solution where all info keys are void* and the users manage their content?
> Having multiple keys will allow several layers of the software stack to save
> their own custom values without collisions, while the void* make a good
> generalization of the stored information.
>
> George.
>
>
>
> On Aug 24, 2012, at 7:09, Brice Goglin <brice.gog...@inria.fr> wrote:
>
>> Le 24/08/2012 11:46, Jeff Squyres a écrit :
>>> On Aug 24, 2012, at 4:26 AM, Brice Goglin wrote:
>>>
>>>> The question that remains is about the naming. Right now, it's
>>>> "valarray" but it don't like it. What it really means is "custom array
>>>> of float values". Maybe just "values", or "floats", or "custom floats",
>>>> or ... ?
>>> Random question: why floats and not doubles?
>> Likely because we have floats in the distance matrices but it didn't
>> matter for this use.
>>
>>> Another name suggestion: cached_floats (cached_doubles)
>> It's not really about caching, it's more about annotating the topology
>> by merging multiple inputs together (XML topology + benchmark outputs +
>> application info) inside the same XML file.
>>
>>> If the goal is to be able to store some data that will also show up in the
>>> XML (and text/gui output?)
>> I don't plan to display any of this to lstopo.
>>
>>> , why not make the mechanism more general? E.g., the values array should
>>> be a union, with an enum indicating its type, and support a small number of
>>> intrinsic types: float (or double), string, int (and/or long?).
>>>
>> I thought about that but I wasn't sure it was worth doing it. When you
>> say type, are you talking about the type that appears in the array of
>> values, or about the global annotation type?
>>
>> I though about doing this
>>
>> struct values {
>> char *name;
>> type /* FLOATS or something else in the future */
>> union {
>> floats {
>> unsigned nr;
>> unsigned *indexes;
>> floats *values;
>> };
>> };
>> };
>>
>> This is vague enough to support other kinds of annotations (even if I
>> don't expect many additions). Ideally, we would merge the "info"
>> attribute into this, but it would break the ABI (because of the
>> get_info_by_name() inline function).
>>
>> You're talking about this instead?
>>
>> struct values {
>> char *name;
>> type /* DOUBLE or ULLONG */
>> unsigned nr;
>> unsigned * indexes;
>> void * values; /* sizeof(type) * nr */
>> };
>>
>> This one is easy to implement. Not sure if we would want
>> float/double/int/long/ulong/llong/... or only double/ullong. I just need
>> something clear enough for importing/exporting as string in the XML output.
>>
>> String is really needed since we have info attributes. It's not an
>> array, but I don't think it matters much.
>>
>> Brice
>>
>> _______________________________________________
>> 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
