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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
