Hi John stdint.h is part of standard headers (C99?), I think you shouldn't use standard headers for kernel when there are such "kernel headers" for same proprose. If the developers created that specific headers for kernel, they should have a good reason for it. I have a pertinent question on this topic too, I've been using *aways* u8, u16, u32 in kernel code (driver code) and *aways* __u8, __u16, __u32 for code that goes to both (usualy ioctl definition headers). What is happening here is that __u8 from userspace is being "casted" to u8 in driver during an ioctl call, is that a problem? This is the "right way to do it", right? Also, LDD3 stats this: It's important to remember that these types are Linux specific, and using them hinders porting software to other Unix flavors. Systems with recent compilers support the C99-standard types, such as uint8_t and uint32_t; if portability is a concern, those types can be used in favor of the Linux-specific variety [1]. So using C99 standard types for userspace headers (ioctl headers for example) are okay!? [1] http://www.makelinux.net/ldd3/chp-11-sect-2 2016-04-15 9:37 GMT-03:00 John Chludzinski <john.chludzinski@xxxxxxxxxxx>: > Never use stdint.h? Wasn't that the intent of stdint.h ... for kernel > code? For embedded code? > > ---John > > On 2016-04-15 08:27, Greg KH wrote: >> On Fri, Apr 15, 2016 at 08:04:53AM -0400, Robert P. J. Day wrote: >>> >>> is there a single, decent online doc that explains the proper data >>> types (int16_t, int32_t and so on) to use in kernel code? >> >> First off, never use int16_t and friends, that's not ok :) >> >> Second, it's simple, use: >> u8 >> u16 >> u32 >> u64 >> and friends in kernel code (s8, s16, and so on for signed values.) >> >> 'int' is a return type, and for loops and other things that you know >> will fit in that size. >> >>> including the relationship with types to be used in code to be >>> exported to user space (include/uapi/linux/types.h)? >> >> For values that cross the user/kernel boundry, add '__' to the front of >> the variable: >> __u8 >> __u16 >> __u32 >> and so on. NEVER use 'int' or 'long' crossing that boundry, it's not >> going to work properly. >> >> I think one of the chapters in LDD3 describes all of this, you might >> want to re-read it for the details. >> >> hope this helps, >> >> greg k-h >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies@xxxxxxxxxxxxxxxxx >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- "Do or do not. There is no try" Yoda Master _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
