Data Type used in kernel .

[greg@kroah.com (Greg KH)]

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