single, comprehensive kernel data types document?

[Greg KH]

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