Comedi use of standard types

Ian Abbott abbotti at mev.co.uk
Wed Feb 22 11:46:07 UTC 2017


On 21/02/17 21:27, Tobin C. Harding wrote:
> Comedi drivers make heavy use of standard types i.e unsigned
> short. According to Linux Device Drivers standard C data types are not
> the same size of all architectures.
>
> Should we be converting comedi/drivers to use kernel types u8, u16 etc

Linux kernel C data types have stricter requirements than the C standard 
allows.  There is common agreement on the widths of 'char', 'short', 
'int', and 'long long', a choice of two widths for 'long'.  Signed 
integers are assumed to use 2's complement representation, and null 
pointers are assumed to have an "all bits zero" representation. 
Obviously, the "endianness" of the types will be arch-specific.  (I 
probably missed some stuff.  For example, I'm not sure if the Linux 
kernel requires a plain 'char' to be signed.  And I don't know if any of 
this is officially documented anywhere, so count it as my opinion.)

> Follow up question. Some comedi/drivers also use unsigned long for
> variables that are not memory addresses. If we are to convert standard
> types to kernel types how does one know the intended size of these
> variables. I see that the register values come from the manual
>
> http://www.ni.com/pdf/manuals/340934b.pdf
>
> Is the choice (size) of type in a struct (eg struct ni_private,
> comedi/drivers/ni_stc.h) a kernel design issue or is it a hardware
> issue and should I be reading the manual to find it.

It's mostly a design issue.  In general, there is no harm in making 
local variables wider than they need to be up to 'int' size, although 
the exact-width types such as 'u16' may be useful sometimes.  In 
general, structure members and array elements should not be excessively 
wide.  The use of 'long' or 'unsigned long' should be viewed with 
suspicion unless there is a specific reason for it.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti at mev.co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-


More information about the devel mailing list