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