[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