Data Type used in kernel .

[Nicholas Mc Guire]

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 at 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