Take you through the Linux kernel source code programming specifications

This is a short article that describes the preferred code style that describes the linux kernel. The purpose is to share that, as a linux kernel or drive development engineer, it is important to understand these kernel development specifications.

• These conventions or specifications are of great help to us to read linux kernel source code and understand design ideas.

• We do development based on linux kernel, but also add code to the kernel, follow development specifications, and help others read and understand our code.

linux kernel code specification conventions are as follows:

1. It is highly recommended that the width of a single row be 80 columns.

Any statement that is more than 80 columns wide should be split into rows unless a section that exceeds 80 columns improves readability and does not hide information. However, do not split user-visible strings, such as printk information, into multiple lines, as this will result in the information not being found when using grep

2. About braces

if do while for for in the c language are used in braces, kernel code tends to place the opening parenthesis at the end of the line, the closing parenthesis at the beginning of the line, and the braces and the preceding statements, as well as if and subsequent statements, all leave a space, such as:

The above red circle labels all represent a space.

3. About spaces

Let's list this separately, because there are too many spaces in the kernel code.

Linux kernel-style spaces are mainly used on keywords, i.e. add a space after the keywords. Notable exceptions are keywords that look like functions, such as sizeof typeof alignof attribute and in Linux the use of these keywords comes with a pair of parentheses, such as sizeof(int)

So you need to add a space after these keywords:

if, switch, case, for, do, while

However, sizeof typeof alignof attribute does not need to add spaces after that:

s = sizeof(struct file);

When declaring a pointer or returning a function with a value of pointer, the asterisk should be positioned next to the variable name or function name, not the type name, for example:

char linux_banner; u nsigned long long memparse(char ptr, char * retptr); char match_strdup(substring_t *s);

Add a space around the binary operator and the triple operator, for example:

= + - < > * / % | & ^ <= >= == != ? :

But don't add spaces after the monary operator:

• • • ~ ! sizeof typeof alignof attribute defined

4. Variable naming

C is a simple, coarse language, so your name should also be concise. T he definition of variables in the linux kernel should be as simple as possible, and the simpler the better without ambiguity. Y ou can use underscores, but capital letters are definitely not recommended. Therefore, variables and function definitions in the kernel do not use hump nomenclase.

5. Function

Functions should be short and concise, and a function does only one thing. Hundreds of lines of code to form a function are not recommended.

It is best to leave a comment on the front of the key function. This allows others to quickly understand your code intent:

6. Comments

The recommended format for multi-line comments is as follows:

/*

• To support ISA shared interrupts, we need to have one interrupt
• handler that ensures that the IRQ line has been deasserted
• before returning. Failing to do this will result in the IRQ
• line being stuck active, and, since ISA irqs are edge triggered,
• no more IRQs will be seen. */

7. It is recommended to use function self-commenting

The so-called function self-commenting, that is, from your function name can guess what you want to do, such as the kernel:

wait_event(), wait_event_interruptible(), wait_event_interruptible_timeout (), etc.

Note that writing code is not only to the present self, but also to the future self, but also to others to see. If you look back at the code you wrote a year ago, it means that your code specification is problematic.

8. Constant macros and enumerations are named in capitals:

9. Print kernel or drive information

Writing good debugging information can be a huge challenge, and once you're done, it can be hugely helpful for remote debugging

Many subsystems have Kconfig debugging options in their corresponding makefile to open -DDEBUG or to define #define DEBUG printk (KERN_DEBUG ...) can be used to print debug information when it can be printed unconditionally, or #ifdef segments related to debugging have been compiled.

10. Inline function (inline)

Inline keyword allows the compiler to insert and replace the specified function body with each place where the function is called (context), saving extra time for each call to the function. H owever, the proliferation of inline keywords can make the kernel larger, slowing down the entire system because the large kernel consumes more CPU caches and reduces the cache of available memory pages. I magine that a single page cache miss can result in one disk addressing, which takes at least 5 milliseconds. 5 milliseconds is enough for the CPU to run many, many instructions.

Well, that's the convention for some of the code specifications we have when we read linux kernel source code. linux source code as the world's most standardized, the most rigorous code, there is indeed a lot to learn. S ometimes there's always a pleasing feeling when you appreciate kernel code, which may have something to do with their good code specifications. Hopefully this will help you, and then students interested in Linux can take a look at the tutorial

Linux tutorial: https://www.w3cschool.cn/linux/

Linux Microsyscope: https://www.w3cschool.cn/minicourse/play/linuxcourse

Linux should learn this: https://www.w3cschool.cn/linuxprobe/