On Fri, Apr 15, 2016 at 03:59:09PM +0000, Nicholas Mc Guire wrote:
On Fri, Apr 15, 2016 at 05:27:24AM -0700, 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.)
I don´t think its quite that simple - as an exampe here is a part of the variations of chars that exist in the kernel:
Type : equivalent types (basis 4.0 x86 64) char : signed char, __signed__ char, __s8, s8, int8_t unsigned char : unsigned char, u_char, __u8, u8, unchar, u_int8_t, uint8_t __ticket_t, insn_byte_t, kprobe_opcode_t
And that's a mess, which is why not all of those are supposed to cross the user/kernel boundry.
Now for new unsigned char objects it might be good enough to simply use u8 but it does depend on the subsystem and if that has some typedef in use or not or readability could really suffer.
One might argue that the subsystem should be fixed up to not use such crazy typedefs :)
It would however make a lot of sense I belive if a list of types that should be used and which should no longer be used were available. Probably a number of the above typedef might actually be deprecated for any new code (and char is actually one of the shorter lists - unsigned short, unsigned int, unsigned long have atleast 25 equivalent typedefs each).
So a typedef cleanup would make a lot of sense for new conributors and it would also help readability as well as make static code analysis easier...
If the above recommendation {u,s}{8,16,32,64} is somehow official policy for new code, then it maybe should go into Documentation/CodingStyle ?
The question was about the user/kernel boundry, and for that, you HAVE to use the "__" types, otherwise it will be broken. Within the kernel, yes, you can use lots of different types for the same "real" variable size, but you shouldn't, just use the well-known and common types "u8" and you will be fine. Those other ones are there due to code being brought in from all over the place, that's what happens with a codebase of 20 million lines at times :) So, if someone is looking at doing some cleanup patches, I think you found a nice place to start... good luck! greg k-h