[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 ofw mailing list