Shulou(Shulou.com)06/01 Report--

What this article shares with you is about how to understand the coding style of Linux kernel drivers. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

Recently, I was submitting some drivers to the Linux kernel, and in the process of submitting, I found that my code was still much worse than the coding style requirements of the Linux kernel. At the beginning, I only skimmed the CodingStyle in the kernel document, and I didn't take care of a lot of details when I really wrote the code. However, I am not alone in the army of programmers who do not follow the rules. If you look at the code under drivers/staging, you will find that many drivers do not strictly adhere to the kernel's coding style, and in many drivers' TODO files, they will take "checkpatch.pl fixes" as one of their goals (checkpatch.pl is a script used to check whether the code conforms to coding style).

Undeniably, coding style is a matter in which the benevolent see benevolence and the wise see wisdom. For example, the Hungarian nomenclature advocated by Microsoft, in the view of Linus, is the practice of its brain damaged. You may not approve of the coding style developed by Linus, but when it comes to submitting kernel drivers, * * still takes the big picture into account. For such a huge bazaar development, writing code at will will lead to a serious maintainability disaster.

Some aids

When the contemporary code volume reaches a certain level, it is a very tedious task to check and modify coding style manually, but fortunately, we still have some tools to use.

Scripts/checkpatch.pl

This is a script that checks whether the code conforms to the kernel coding specification. As the name implies, checkpatch is used to check patch, and the default call does. If used to check the original file, you need to add the "- f" option.

Let's take a look at a boring piece of code (file name print_msg.c):

Void print_msg (int a) {switch (a) {case 1: printf ("a = = 1\ n"); break; case 2: printf ("a = = 2\ n"); break;}}

Is there a problem with the coding style of this code? Check with checkpatch.pl:

Scripts/checkpatch.pl-f print_msg.c

The results of the examination are:

ERROR: switch and case should be at the same indent # 3: FILE: switch.c:3: + switch (a) {+ case 1: [...] + case 2: total: 1 errors, 0 warnings, 12 lines checked switch.c has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS.

In the coding style of the Linux kernel, switch and case require the same indentation. There is very little code in this example, and there is only one error, so it is convenient to modify it manually. What if there are many similar tightening errors?

Scripts/Lindent

The tool Lindent in the scripts directory can be used to automatically modify indentation problems. As a reminder, using Lindent requires the system to install the tool indent.

For the above example, execute the Lindent command:

Scripts/Lindent print_msg.c

The new code you get is:

Void print_msg (int a) {switch (a) {case 1: printf ("a = = 1\ n"); break; case 2: printf ("a = = 2\ n"); break;}}

Sed

Sed is a stream editor, and its powerful features can help us deal with a lot of repetitive work. For example, the coding style of the Linux kernel requires that there can be no spaces at the end of a line (including Tab), and sed can be used to remove these spaces.

My own habits are so bad that I often leave spaces at the end of the line of code. For example, when a line of code is too long and needs to wrap, always subconsciously type a space in the place of the new line. In addition, Kate, one of my commonly used editors, often leaves a few indented Tab in front of blank lines for alignment (see figure below).

Manually removing the spaces at the end of these lines is a big deal, but it's just a piece of cake for sed. The format of the command is as follows:

Sed's / [\ t] * $/ / g 'your_code.c

Some Coding Style that need to be paid attention to

Indent

1. Except for comments, documentation, and Kconfig, use Tab indentation instead of spaces, and the width of Tab is 8 characters

2. Switch... Case... Statement, switch and case have the same indentation (see above)

Curly braces

3. The use of curly braces refers to the Krabr style.

If it is a function, there is another line in the left curly bracket:

Int function (int x) {body of function}

Otherwise, the curly braces are immediately followed by the * * of the statement:

If (x is true) {we do y}

If there is only one line of statement, you do not need to use curly braces:

If (condition) action ()

However, for conditional statements, if one branch is an one-line statement and the other branch is multiple lines, you need to be consistent and use curly braces:

If (condition) {do_this (); do_that ();} else {otherwise ();}

Space

4. Add a space after the keywords "if, switch, case, for, do, while", such as:

If (something)

5. Do not add spaces after the keywords "sizeof, typeof, alignof, or _ _ attribute__", such as:

Sizeof (struct file)

6. do not add spaces on both sides of the expression in parentheses, for example, here is a negative example:

Sizeof (struct file)

7. most of the binary and ternary operators need spaces on both sides, such as "= + -"

* /% | & ^ =!?: "

8. Do not leave spaces after the unary operator, such as "& * +-~! sizeof typeof alignof _ _ attribute__ defined"

9. Spaces ("+" and "-") are not required after the prefix increment and subtraction operators and before the suffix increment and subtraction operators

10. Structure member operator ("." No spaces are required on both sides of and "- >")

11. No space is required at the end of the line

Annotation

12. Use the "/ *" style of C89 instead of "/ /" of C99. " Style

13. For multiline comments, you can refer to the following example:

/ * * This is the preferred style for multi-line * comments in the Linux kernel source code. * Please use it consistently. * * Description: A column of asterisks on the left side, * with beginning and ending almost-blank lines. , /

Kconfig

14. "config" defines that the following statement is indented with Tab, and the statement under help is indented by two additional spaces, such as:

Config AUDIT bool "Auditing support" depends on NET help Enable auditing infrastructure that can be used with another kernel subsystem, such as SELinux (which requires this for logging of avc messages output). Does not do system-call auditing without CONFIG_AUDITSYSCALL.

Macro

15. Multi-line macro definitions need to be encapsulated with "do.. while", such as:

# define macrofun (a, b, c)\ do {\ if (a = = 5)\ do_this (b, c);\} while (0)

Function return value

16. The definition of the return value of the function should also follow certain rules.

If the name of a function is an action or imperative statement, it should be returned in the form of an error code (usually 0 for success, and a negative number like-Exxx for error), such as:

Do_something ()

If the name of the function is a judgment statement, the return value should be similar to a Boolean value (usually 1 for success, 0 for error), such as:

Something_is_present ()

The above is how to understand the coding style of Linux kernel drivers, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.