Data Type used in kernel .
Greg KH
greg at kroah.com
Sat Dec 24 04:37:50 EST 2016
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 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.
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
More information about the Kernelnewbies
mailing list