[ofa-general] RE: [ofw] [RFC] 2/5: IB ACM: windows abstractions

Sean Hefty sean.hefty at intel.com
Thu Sep 17 00:20:01 PDT 2009


>> An attempt was made to limit the number of dependencies on external
>> libraries,
>> such as complib.  We add Windows support for the Linux 'search' binary
>> tree interfaces.  This is implemented on Windows using complib
>> fleximap, but
>> gets linked in statically.
>
>Should we make complib a static library?  I don't know if the memory savings
>are that great when most users only use a fraction of the complib
>functionality.  If I have time I'll take a look at file sizes and report back.

I don't know if it matters much.  Making it static could actually make the
overall stack smaller.  For windows, it's trivial to pull in the needed complib
source files statically, since it's one big build tree.  I initially tried to
limit the acm to only being dependent on libibverbs, but it's just too much work
long term to avoid using libibumad.  But I really don't want to have it depend
on opensm in order to pick up complib when a short header file can provide
what's needed.

>
>> void *tsearch(const void *key, void **rootp,
>> 			  int (*compar)(const void *, const void *))
>> {
>> 	cl_fmap_item_t *item, *map_item;
>>
>> 	if (!*rootp) {
>> 		*rootp = malloc(sizeof(cl_fmap_t));
>
>You need to check that malloc returned you memory.
>
>> 		cl_fmap_init((cl_fmap_t *) *rootp, fcompare);
>> 	}
>>
>> 	compare = compar;
>> 	item = malloc(sizeof(cl_fmap_item_t));
>
>Ditto.

er... yeah





More information about the general mailing list