Data Type used in kernel .
Hi , I have seen "bool" data type is used in linux kernel code . Can we get documentation on data type used in linux kernel development ? -- Thanks and Regards Wasim Akram Ph: 7702843288
Hello Wasim, On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com> wrote:
Hi ,
I have seen "bool" data type is used in linux kernel code . Can we get documentation on data type used in linux kernel development ?
I think this should be a good start: http://lxr.free-electrons.com/source/include/linux/types.h
--
Thanks and Regards
Wasim Akram Ph: 7702843288
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
Hello Wasim,
On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com> wrote:
Hi ,
I have seen "bool" data type is used in linux kernel code . Can we get documentation on data type used in linux kernel development ?
I think this should be a good start: http://lxr.free-electrons.com/source/include/linux/types.h
one of the problems though is that there are a number of "historic" type systems "left over" in the kernel it seems so there actually is a bit of a mess and its not simple to figure out what things really are. For x86_64 I have a list of type matches I use for code reading (still not complete) which might help. x86 64bit: ========== Type : equivalent types bool : _Bool, 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 short : signed short, __signed__ short, s16, int16_t unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t, __sum16, umode_t, __ticketpair_t, apm_eventinfo_t, apm_event_t, Elf32_Sword, Elf32_Half, Elf64_Half, Elf64_SHalf, __kernel_sa_family_t, __kernel_gid16_t, gid16_t, __kernel_uid16_t, uid16_t, __kernel_old_uid_t, old_uid_t, __kernel_old_gid_t, old_gid_t, arch cond: __le16/__be16 int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t Elf64_Sword, Elf64_Sxword, key_serial_t, insn_value_t, __kernel_daddr_t, daddr_t, __kernel_ipc_pid_t, pid_t, __kernel_pid_t, __kernel_mqd_t, mqd_t, __kernel_key_t, key_t, __kernel_timer_t timer_t, unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t, __wsum, nlink_t, gfp_t, fmode_t, oom_flags_t, isolate_mode_t, Elf32_Addr, Elf32_Off, Elf32_Word, Elf64_Word, key_perm_t, insn_attr_t, sk_buff_data_t, sctp_assoc_t. __kernel_dev_t, dev_t, __kernel_uid32_t, uid_t, projid_t, qid_t __kernel_gid32_t, gid_t, __kernel_uid_t, __kernel_gid_t, __kernel_mode_t, mode_t, arch cond: __le32/__be32 long : signed long, __kernel_long_t, __kernel_suseconds_t, suseconds_t, __kernel_ssize_t, ssize_t, __kernel_ptrdiff_t, __kernel_off_t, off_t, __kernel_time_t, time_t, __kernel_clock_t, clock_t, unsigned long : __kernel_ulong_t, u_long, ulong uintptr_t, sector_t, blkcnt_t, irq_hw_number_t, pteval_t, pmdval_t, pudval_t, pgdval_t, pgprotval_t, vm_flags_t, elf_greg_t, cputime_t, old_sigset_t, aio_context_t, flow_compare_t, __kernel_ino_t, ino_t __kernel_old_dev_t __kernel_size_t. size_t, arch cond: __le64/__be64 long long : signed long long, __signed__ long long, __s64, s64, int64_t time64_t, qsize_t, __kernel_loff_t, loff_t, unsigned long long: u64, __u64, uint64_t, u_int64_t dma_addr_t, cycles_t, phys_addr_t, resource_size_t cycle_t, Elf64_Addr, Elf64_Off, Elf64_Xword, cputime64_t, netdev_features_t
On Fri, Dec 23, 2016 at 11:52:33AM +0000, Nicholas Mc Guire wrote:
On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
Hello Wasim,
On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com> wrote:
Hi ,
I have seen "bool" data type is used in linux kernel code . Can we get documentation on data type used in linux kernel development ?
I think this should be a good start: http://lxr.free-electrons.com/source/include/linux/types.h
one of the problems though is that there are a number of "historic" type systems "left over" in the kernel it seems so there actually is a bit of a mess and its not simple to figure out what things really are. For x86_64 I have a list of type matches I use for code reading (still not complete) which might help.
x86 64bit: ==========
Type : equivalent types bool : _Bool, 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 short : signed short, __signed__ short, s16, int16_t unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t, __sum16, umode_t, __ticketpair_t, apm_eventinfo_t, apm_event_t, Elf32_Sword, Elf32_Half, Elf64_Half, Elf64_SHalf, __kernel_sa_family_t, __kernel_gid16_t, gid16_t, __kernel_uid16_t, uid16_t, __kernel_old_uid_t, old_uid_t, __kernel_old_gid_t, old_gid_t, arch cond: __le16/__be16 int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t Elf64_Sword, Elf64_Sxword, key_serial_t, insn_value_t, __kernel_daddr_t, daddr_t, __kernel_ipc_pid_t, pid_t, __kernel_pid_t, __kernel_mqd_t, mqd_t, __kernel_key_t, key_t, __kernel_timer_t timer_t, unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t, __wsum, nlink_t, gfp_t, fmode_t, oom_flags_t, isolate_mode_t, Elf32_Addr, Elf32_Off, Elf32_Word, Elf64_Word, key_perm_t, insn_attr_t, sk_buff_data_t, sctp_assoc_t. __kernel_dev_t, dev_t, __kernel_uid32_t, uid_t, projid_t, qid_t __kernel_gid32_t, gid_t, __kernel_uid_t, __kernel_gid_t, __kernel_mode_t, mode_t, arch cond: __le32/__be32 long : signed long, __kernel_long_t, __kernel_suseconds_t, suseconds_t, __kernel_ssize_t, ssize_t, __kernel_ptrdiff_t, __kernel_off_t, off_t, __kernel_time_t, time_t, __kernel_clock_t, clock_t, unsigned long : __kernel_ulong_t, u_long, ulong uintptr_t, sector_t, blkcnt_t, irq_hw_number_t, pteval_t, pmdval_t, pudval_t, pgdval_t, pgprotval_t, vm_flags_t, elf_greg_t, cputime_t, old_sigset_t, aio_context_t, flow_compare_t, __kernel_ino_t, ino_t __kernel_old_dev_t __kernel_size_t. size_t, arch cond: __le64/__be64 long long : signed long long, __signed__ long long, __s64, s64, int64_t time64_t, qsize_t, __kernel_loff_t, loff_t, unsigned long long: u64, __u64, uint64_t, u_int64_t dma_addr_t, cycles_t, phys_addr_t, resource_size_t cycle_t, Elf64_Addr, Elf64_Off, Elf64_Xword, cputime64_t, netdev_features_t
That's crazy. Just use the data types that the LDD book says to use for in-kernel code: u8, u16, u32, u64, s8, s16, s32, s64, int, bool and if the data crosses the user/kernel boundry, use the correct ones for that (__ in front, no int). You can use others, but you better know what you are doing if you do :) Hope this helps, greg k-h
On Fri, Dec 23, 2016 at 07:01:37PM +0100, Greg KH wrote:
On Fri, Dec 23, 2016 at 11:52:33AM +0000, Nicholas Mc Guire wrote:
On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
Hello Wasim,
On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com> wrote:
Hi ,
I have seen "bool" data type is used in linux kernel code . Can we get documentation on data type used in linux kernel development ?
I think this should be a good start: http://lxr.free-electrons.com/source/include/linux/types.h
one of the problems though is that there are a number of "historic" type systems "left over" in the kernel it seems so there actually is a bit of a mess and its not simple to figure out what things really are. For x86_64 I have a list of type matches I use for code reading (still not complete) which might help.
x86 64bit: ==========
Type : equivalent types bool : _Bool, 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 short : signed short, __signed__ short, s16, int16_t unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t, __sum16, umode_t, __ticketpair_t, apm_eventinfo_t, apm_event_t, Elf32_Sword, Elf32_Half, Elf64_Half, Elf64_SHalf, __kernel_sa_family_t, __kernel_gid16_t, gid16_t, __kernel_uid16_t, uid16_t, __kernel_old_uid_t, old_uid_t, __kernel_old_gid_t, old_gid_t, arch cond: __le16/__be16 int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t Elf64_Sword, Elf64_Sxword, key_serial_t, insn_value_t, __kernel_daddr_t, daddr_t, __kernel_ipc_pid_t, pid_t, __kernel_pid_t, __kernel_mqd_t, mqd_t, __kernel_key_t, key_t, __kernel_timer_t timer_t, unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t, __wsum, nlink_t, gfp_t, fmode_t, oom_flags_t, isolate_mode_t, Elf32_Addr, Elf32_Off, Elf32_Word, Elf64_Word, key_perm_t, insn_attr_t, sk_buff_data_t, sctp_assoc_t. __kernel_dev_t, dev_t, __kernel_uid32_t, uid_t, projid_t, qid_t __kernel_gid32_t, gid_t, __kernel_uid_t, __kernel_gid_t, __kernel_mode_t, mode_t, arch cond: __le32/__be32 long : signed long, __kernel_long_t, __kernel_suseconds_t, suseconds_t, __kernel_ssize_t, ssize_t, __kernel_ptrdiff_t, __kernel_off_t, off_t, __kernel_time_t, time_t, __kernel_clock_t, clock_t, unsigned long : __kernel_ulong_t, u_long, ulong uintptr_t, sector_t, blkcnt_t, irq_hw_number_t, pteval_t, pmdval_t, pudval_t, pgdval_t, pgprotval_t, vm_flags_t, elf_greg_t, cputime_t, old_sigset_t, aio_context_t, flow_compare_t, __kernel_ino_t, ino_t __kernel_old_dev_t __kernel_size_t. size_t, arch cond: __le64/__be64 long long : signed long long, __signed__ long long, __s64, s64, int64_t time64_t, qsize_t, __kernel_loff_t, loff_t, unsigned long long: u64, __u64, uint64_t, u_int64_t dma_addr_t, cycles_t, phys_addr_t, resource_size_t cycle_t, Elf64_Addr, Elf64_Off, Elf64_Xword, cputime64_t, netdev_features_t
That's crazy. Just use the data types that the LDD book says to use for
Its crazy but the problem is that if you use basic data types to handle any of those types that are in use it actually can end up being more confusing that if you do not - for the basic types using the list you give below (rather than any of those historic variatsion makes sense.
in-kernel code: u8, u16, u32, u64, s8, s16, s32, s64, int, bool
It would be good to add a statement to CodingStyle stating something like this. While the section 5) Typedefs does mention guidlines it does not give a clear preference - would something like: <snip> With all this said on typedef usage (or rather prefered non-usage) the prefered type system for any kernel only variables used is: u8, u16, u32, u64, s8, s16, s32, s64, int, bool and for anything shared between kernel and user-space: __u8, __u16, __u32, __u64, __s8, __s16, __s32, __s64, bool <snip> be appropriate ?
and if the data crosses the user/kernel boundry, use the correct ones for that (__ in front, no int).
You can use others, but you better know what you are doing if you do :)
and section 5) of Documentation/process/coding-style.rst does give some guidlines for creating new types. thx! hofrat
On Sat, Dec 24, 2016 at 08:06:25AM +0000, Nicholas Mc Guire wrote:
On Fri, Dec 23, 2016 at 07:01:37PM +0100, Greg KH wrote:
On Fri, Dec 23, 2016 at 11:52:33AM +0000, Nicholas Mc Guire wrote:
On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
Hello Wasim,
On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com> wrote:
Hi ,
I have seen "bool" data type is used in linux kernel code . Can we get documentation on data type used in linux kernel development ?
I think this should be a good start: http://lxr.free-electrons.com/source/include/linux/types.h
one of the problems though is that there are a number of "historic" type systems "left over" in the kernel it seems so there actually is a bit of a mess and its not simple to figure out what things really are. For x86_64 I have a list of type matches I use for code reading (still not complete) which might help.
x86 64bit: ==========
Type : equivalent types bool : _Bool, 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 short : signed short, __signed__ short, s16, int16_t unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t, __sum16, umode_t, __ticketpair_t, apm_eventinfo_t, apm_event_t, Elf32_Sword, Elf32_Half, Elf64_Half, Elf64_SHalf, __kernel_sa_family_t, __kernel_gid16_t, gid16_t, __kernel_uid16_t, uid16_t, __kernel_old_uid_t, old_uid_t, __kernel_old_gid_t, old_gid_t, arch cond: __le16/__be16 int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t Elf64_Sword, Elf64_Sxword, key_serial_t, insn_value_t, __kernel_daddr_t, daddr_t, __kernel_ipc_pid_t, pid_t, __kernel_pid_t, __kernel_mqd_t, mqd_t, __kernel_key_t, key_t, __kernel_timer_t timer_t, unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t, __wsum, nlink_t, gfp_t, fmode_t, oom_flags_t, isolate_mode_t, Elf32_Addr, Elf32_Off, Elf32_Word, Elf64_Word, key_perm_t, insn_attr_t, sk_buff_data_t, sctp_assoc_t. __kernel_dev_t, dev_t, __kernel_uid32_t, uid_t, projid_t, qid_t __kernel_gid32_t, gid_t, __kernel_uid_t, __kernel_gid_t, __kernel_mode_t, mode_t, arch cond: __le32/__be32 long : signed long, __kernel_long_t, __kernel_suseconds_t, suseconds_t, __kernel_ssize_t, ssize_t, __kernel_ptrdiff_t, __kernel_off_t, off_t, __kernel_time_t, time_t, __kernel_clock_t, clock_t, unsigned long : __kernel_ulong_t, u_long, ulong uintptr_t, sector_t, blkcnt_t, irq_hw_number_t, pteval_t, pmdval_t, pudval_t, pgdval_t, pgprotval_t, vm_flags_t, elf_greg_t, cputime_t, old_sigset_t, aio_context_t, flow_compare_t, __kernel_ino_t, ino_t __kernel_old_dev_t __kernel_size_t. size_t, arch cond: __le64/__be64 long long : signed long long, __signed__ long long, __s64, s64, int64_t time64_t, qsize_t, __kernel_loff_t, loff_t, unsigned long long: u64, __u64, uint64_t, u_int64_t dma_addr_t, cycles_t, phys_addr_t, resource_size_t cycle_t, Elf64_Addr, Elf64_Off, Elf64_Xword, cputime64_t, netdev_features_t
That's crazy. Just use the data types that the LDD book says to use for
Its crazy but the problem is that if you use basic data types to handle any of those types that are in use it actually can end up being more confusing that if you do not - for the basic types using the list you give below (rather than any of those historic variatsion makes sense.
I don't understand what you mean here. When would someone from kernelnewbies ever have to deal with Elf64_Off?
in-kernel code: u8, u16, u32, u64, s8, s16, s32, s64, int, bool
It would be good to add a statement to CodingStyle stating something like this. While the section 5) Typedefs does mention guidlines it does not give a clear preference - would something like:
<snip> With all this said on typedef usage (or rather prefered non-usage) the prefered type system for any kernel only variables used is:
u8, u16, u32, u64, s8, s16, s32, s64, int, bool
and for anything shared between kernel and user-space:
__u8, __u16, __u32, __u64, __s8, __s16, __s32, __s64, bool <snip>
be appropriate ?
Nope, just don't create new typedefs and you should be fine, coding style already says that.
and if the data crosses the user/kernel boundry, use the correct ones for that (__ in front, no int).
You can use others, but you better know what you are doing if you do :)
and section 5) of Documentation/process/coding-style.rst does give some guidlines for creating new types.
Yes, please do not create any new types, and you should be fine. thanks, greg k-h
participants (4)
-
Greg KH -
Nicholas Mc Guire -
Pasquier, Thomas -
Wasim Akram