* Data Type used in kernel . @ 2016-12-23 11:20 Wasim Akram 2016-12-23 11:33 ` Pasquier, Thomas 0 siblings, 1 reply; 6+ messages in thread From: Wasim Akram @ 2016-12-23 11:20 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel . 2016-12-23 11:20 Data Type used in kernel Wasim Akram @ 2016-12-23 11:33 ` Pasquier, Thomas 2016-12-23 11:52 ` Nicholas Mc Guire 0 siblings, 1 reply; 6+ messages in thread From: Pasquier, Thomas @ 2016-12-23 11:33 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161223/761a0c97/attachment.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel . 2016-12-23 11:33 ` Pasquier, Thomas @ 2016-12-23 11:52 ` Nicholas Mc Guire 2016-12-23 18:01 ` Greg KH 0 siblings, 1 reply; 6+ messages in thread From: Nicholas Mc Guire @ 2016-12-23 11:52 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel . 2016-12-23 11:52 ` Nicholas Mc Guire @ 2016-12-23 18:01 ` Greg KH 2016-12-24 8:06 ` Nicholas Mc Guire 0 siblings, 1 reply; 6+ messages in thread From: Greg KH @ 2016-12-23 18:01 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel . 2016-12-23 18:01 ` Greg KH @ 2016-12-24 8:06 ` Nicholas Mc Guire 2016-12-24 9:37 ` Greg KH 0 siblings, 1 reply; 6+ messages in thread From: Nicholas Mc Guire @ 2016-12-24 8:06 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel . 2016-12-24 8:06 ` Nicholas Mc Guire @ 2016-12-24 9:37 ` Greg KH 0 siblings, 0 replies; 6+ messages in thread From: Greg KH @ 2016-12-24 9:37 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-12-24 9:37 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-23 11:20 Data Type used in kernel Wasim Akram 2016-12-23 11:33 ` Pasquier, Thomas 2016-12-23 11:52 ` Nicholas Mc Guire 2016-12-23 18:01 ` Greg KH 2016-12-24 8:06 ` Nicholas Mc Guire 2016-12-24 9:37 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).