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
