On Wed, Feb 22, 2017 at 11:46:07AM +0000, Ian Abbott wrote: > 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.) char can be signed (x86) or unsigned (s390) depending on the arch, yes. > >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. Long and unsigned long are fairly normal types used everywhere. I don't understand really what Tobin is talking about without a specific example. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
