single, comprehensive kernel data types document?
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? including the relationship with types to be used in code to be exported to user space (include/uapi/linux/types.h)? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
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
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Am 2016-04-15 14:37, schrieb John Chludzinski:
Never use stdint.h? Wasn't that the intent of stdint.h ... for kernel code? For embedded code?
I could be wrong about this but the reason for not using it may be that there is no standard C library where the Kernel lives. Thus using types from stdint.h would be confusing. Also, the string "u16" is much shorter than "uint16_t" and thus must surely be faster! :P Cheers, Silvan
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@vivaldi.net>:
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- "Do or do not. There is no try" Yoda Master
On Fri, Apr 15, 2016 at 10:09:35AM -0300, Daniel. wrote:
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?
Yes, that is correct.
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!?
No, they aren't, you can not used those types for ioctl headers. You can get away with using it in kernel-only code, but really, why would you want to? thanks, greg k-h
2016-04-15 10:55 GMT-03:00 Greg KH <greg@kroah.com>:
On Fri, Apr 15, 2016 at 10:09:35AM -0300, Daniel. wrote:
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?
Yes, that is correct.
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!?
No, they aren't, you can not used those types for ioctl headers.
You can get away with using it in kernel-only code, but really, why would you want to? I don't :),
Thanks for the reply
thanks,
greg k-h
Regards, -- "Do or do not. There is no try" Yoda Master
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 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. 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 ? thx! hofrat
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
On Fri, 15 Apr 2016 09:18:32 -0700, Greg KH said:
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 :)
What's the current feeling on using typedefs to get more type safety?
On Fri, Apr 15, 2016 at 01:07:19PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 15 Apr 2016 09:18:32 -0700, Greg KH said:
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 :)
What's the current feeling on using typedefs to get more type safety?
typedefs are evil, never use them. No non-core-kernel developer should EVER create a new typedef, except for a function pointer signature. greg k-h
Sorry if this isn't related, it seemed like it was... I recently discovered one of our drivers isn't written correctly for 64-bit. It uses a uint32_t to hold an address. Whoops. In previous drivers when I've needed to hold an address, I've used an "unsigned long", as (so far as I could tell) that would give me the correct number of bytes whether on 32 or 64-bit systems. Now that I have to fix this driver, I'd rather do whatever the "standard" method is for storing an address value. Looking at code in the kernel and linux/types.h, I see "phys_addr_t and dma_addr_t. Is that what I want to use? What if it's a virtual address? void *? Thanks. Rob
On Wed, Apr 20, 2016 at 04:37:07PM -0400, Rob Groner wrote:
Sorry if this isn't related, it seemed like it was...
I recently discovered one of our drivers isn't written correctly for 64-bit. It uses a uint32_t to hold an address. Whoops.
In previous drivers when I've needed to hold an address, I've used an "unsigned long", as (so far as I could tell) that would give me the correct number of bytes whether on 32 or 64-bit systems.
Now that I have to fix this driver, I'd rather do whatever the "standard" method is for storing an address value.
Looking at code in the kernel and linux/types.h, I see "phys_addr_t and dma_addr_t. Is that what I want to use? What if it's a virtual address? void *?
You want to use '__u64' and cast properly within the kernel to a pointer. hope this helps, greg k-h
On Thu, 2016-04-21 at 11:51 +0900, Greg KH wrote:
On Wed, Apr 20, 2016 at 04:37:07PM -0400, Rob Groner wrote:
Sorry if this isn't related, it seemed like it was...
I recently discovered one of our drivers isn't written correctly for 64-bit. It uses a uint32_t to hold an address. Whoops.
In previous drivers when I've needed to hold an address, I've used an "unsigned long", as (so far as I could tell) that would give me the correct number of bytes whether on 32 or 64-bit systems.
Now that I have to fix this driver, I'd rather do whatever the "standard" method is for storing an address value.
Looking at code in the kernel and linux/types.h, I see "phys_addr_t and dma_addr_t. Is that what I want to use? What if it's a virtual address? void *?
You want to use '__u64' and cast properly within the kernel to a pointer.
hope this helps,
greg k-h
Thank you Greg. I was thinking there was a type that would hold a memory address (like an allocated DMA buffer address, or a PCI address) that would be the correct size on a 32-bit or 64-bit system without me having to specify a size. If I use __u64 to hold a memory address, won't that be the wrong size on a 32-bit system? Rob
On Thu, Apr 21, 2016 at 08:51:04AM -0400, Rob Groner wrote:
On Thu, 2016-04-21 at 11:51 +0900, Greg KH wrote:
On Wed, Apr 20, 2016 at 04:37:07PM -0400, Rob Groner wrote:
Sorry if this isn't related, it seemed like it was...
I recently discovered one of our drivers isn't written correctly for 64-bit. It uses a uint32_t to hold an address. Whoops.
In previous drivers when I've needed to hold an address, I've used an "unsigned long", as (so far as I could tell) that would give me the correct number of bytes whether on 32 or 64-bit systems.
Now that I have to fix this driver, I'd rather do whatever the "standard" method is for storing an address value.
Looking at code in the kernel and linux/types.h, I see "phys_addr_t and dma_addr_t. Is that what I want to use? What if it's a virtual address? void *?
You want to use '__u64' and cast properly within the kernel to a pointer.
hope this helps,
greg k-h
Thank you Greg.
I was thinking there was a type that would hold a memory address (like an allocated DMA buffer address, or a PCI address) that would be the correct size on a 32-bit or 64-bit system without me having to specify a size. If I use __u64 to hold a memory address, won't that be the wrong size on a 32-bit system?
It will be bigger than is strictly necessary in that specific case, but is that a problem? Also, please consider the case where a user is running a 32-bit userspace and a 64-bit kernel. Not making datastructures which cross the user/kernel boundaries make use of the largest fixed-width[1] type means that the kernel would have to handle this case differently (in fact, you can find many 'compat' examples in the kernel tree which do just that, because the types were incorrectly used). And, that's just terrible :(. Josh 1: Just wanted to add it's not just about size of these datatypes, either. It's about their alignment.
On Thu, Apr 21, 2016 at 08:51:04AM -0400, Rob Groner wrote:
On Thu, 2016-04-21 at 11:51 +0900, Greg KH wrote:
On Wed, Apr 20, 2016 at 04:37:07PM -0400, Rob Groner wrote:
Sorry if this isn't related, it seemed like it was...
I recently discovered one of our drivers isn't written correctly for 64-bit. It uses a uint32_t to hold an address. Whoops.
In previous drivers when I've needed to hold an address, I've used an "unsigned long", as (so far as I could tell) that would give me the correct number of bytes whether on 32 or 64-bit systems.
Now that I have to fix this driver, I'd rather do whatever the "standard" method is for storing an address value.
Looking at code in the kernel and linux/types.h, I see "phys_addr_t and dma_addr_t. Is that what I want to use? What if it's a virtual address? void *?
You want to use '__u64' and cast properly within the kernel to a pointer.
hope this helps,
greg k-h
Thank you Greg.
I was thinking there was a type that would hold a memory address (like an allocated DMA buffer address, or a PCI address) that would be the correct size on a 32-bit or 64-bit system without me having to specify a size. If I use __u64 to hold a memory address, won't that be the wrong size on a 32-bit system?
As Josh says, this is fine, you just "burn" 4 bytes, but you need to do that anyway for alignment and you save for not having a 'compat ioctl' callback to do the pointer fixup that would be required if you were to use a 32bit value for a pointer. And also, as Josh says, consider mixed user/kernel sizes, that gets messy very quickly, so just always make pointers 64bits and all works just fine. hope this helps, greg k-h
On Fri, 22 Apr 2016 11:37:13 +0900, Greg KH said:
As Josh says, this is fine, you just "burn" 4 bytes,
Are there stil any platforms left where that matters? Sure, when I started coding, an HP2114 had all of 8K of RAM, so wasting 4 bytes mattered. But I don't know of anything that will boot Linux and is still so storaged constrained that we care. Heck, even my fairly old wireless router has 128M of RAM on it - and even THERE the 8M of flash is a bigger constraint :)
On Thu, Apr 21, 2016 at 11:02:32PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 22 Apr 2016 11:37:13 +0900, Greg KH said:
As Josh says, this is fine, you just "burn" 4 bytes,
Are there stil any platforms left where that matters? Sure, when I started coding, an HP2114 had all of 8K of RAM, so wasting 4 bytes mattered. But I don't know of anything that will boot Linux and is still so storaged constrained that we care. Heck, even my fairly old wireless router has 128M of RAM on it - and even THERE the 8M of flash is a bigger constraint :)
People cram Linux into machines with only 2M of ram, there are tons of chips out there that are new and shipping in devices with less than 1M of ram that would be great to have Linux running in them, but can't at the moment. So yes, in some systems it does matter, in others, it doesn't but that's the beauty of Linux, it runs almost everywhere :) thanks, greg k-h
participants (9)
-
Daniel. -
Greg KH -
John Chludzinski -
Josh Cartwright -
Nicholas Mc Guire -
Rob Groner -
Robert P. J. Day -
Silvan Jegen -
Valdis.Kletnieks＠vt.edu