[ofa-general] RE: [ofw] RE: PATCH[1/6] Windows port of libibmad - mad.h
Sean Hefty
sean.hefty at intel.com
Fri Dec 19 11:00:04 PST 2008
>>>-void _set_field(void *buf, int base_offs, ib_field_t *f, uint32_t val);
>>>+void _set_field(void *buf, int base_offs, ib_field_t *f, uint32_t val);
>>> uint32_t _get_field(void *buf, int base_offs, ib_field_t *f);
>>>-void _set_array(void *buf, int base_offs, ib_field_t *f, void *val);
>>>-void _get_array(void *buf, int base_offs, ib_field_t *f, void *val);
>>>-void _set_field64(void *buf, int base_offs, ib_field_t *f, uint64_t val);
>>>+void _set_array(void *buf, int base_offs, ib_field_t *f, void *val);
>>>+void _get_array(void *buf, int base_offs, ib_field_t *f, void *val);
>>>+void _set_field64(void *buf, int base_offs, ib_field_t *f, uint64_t val);
>>> uint64_t _get_field64(void *buf, int base_offs, ib_field_t *f);
>>
>> Are these really the functions that should be exported from the library or in
>> the header file? (I'm probably missing some history here.)
>
>For one thing, mad.h currently inlines a number of functions used by
>(diag) applications which invoke these.
I did see that. I was thinking more of renaming _set_field to mad_set_field and
removing the existing implementation of mad_set_field.
- Sean
More information about the general
mailing list