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

How to make Linux kernel source code specification, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Start with the wrong coding style

Once when I was developing the Linux kernel driver, I created a patch file, but when I put the patch to the main branch, I prompted a lot of coding style errors, but later I redid the patch to solve the problem, which is also the problem caused by not strictly following the Linux coding style. Because the amount of code in the era is not large, so the time to solve the problem is relatively less. When the amount of code increases, it can be modified automatically with the help of tools.

A tool for quickly changing the coding style

Scripts/checkpatch.pl

This is a script that checks whether patch conforms to the kernel coding specification. This is also true of the default call. If used to check the original file, you need to add the option of-f.

Scripts/Lindent

The tool Lindent in the scripts directory under the source path can be used to automatically modify indentation problems. However, using Lindent requires the system to install indent as a tool. Apt-get install indent can be used for "installation" on Ubuntu systems.

Astyle

It is recommended to use this tool because it is quite convenient and can be converted to linux,java,gnu style with one click.

Download address Project address document description

How to use, you can refer to the specific documentation, write in more detail.

All in all, we should take the overall situation into account and strictly abide by the coding standards of Linux when carrying out kernel development and driver development, so as to avoid all kinds of problems caused by non-standard coding. You can refer to the Documentation/CodingStyle document under the kernel path. The following is from the Linux kernel document. The most authoritative document path is very powerful. There is already a Chinese version on this website. Thank you very much. Specific updates can be redirected to the URL you know.

"Chinese translation from Documentation/process/coding-style.rst"

Linux kernel code style

This is a short document that describes the preferred code style of the linux kernel. The style of code varies from person to person, and I don't want to impose my views on anyone, but it's like the principle I have to follow in everything I do, and I want to maintain this attitude on most things. Please (when writing code) at least consider the code style here.

First of all, I suggest you print a copy of the GNU code specification, and then don't read it. Burn it. It's a symbolic gesture.

Anyway, now let's start:

1 indent

Tabs are 8 characters, so indentation is also 8 characters. Some heretical movements try to turn indentation into 4 (or even 2!). Character depth, which is almost equivalent to trying to define the value of pi as 3.

Reason: the whole point of indentation is to clearly define where a control block starts and ends. Especially when you stare at your screen for 20 hours in a row, you will find that larger indentation will make it easier for you to distinguish indentation.

Now, some people complain that an 8-character indentation makes the code move too far to the right, which is hard to read on an 80-character terminal screen. The answer to this question is that if you need more than 3 levels of indentation, no matter how your code is already problematic, you should fix your program.

In short, an 8-character indentation makes the code easier to read, and another benefit is that it warns you when your functions are too deeply nested. Heed this warning.

The preferred way to eliminate multi-level indentation in switch statements is to align switch and its subordinate case tags in the same column, rather than indenting case tags twice. For example:

Switch (suffix) {case'Graph: case 'g': mem f))

There are also min () and max () macros that can do strict type checking, and you can use them if you want. You can see for yourself what else is defined in the header file that you can use, and if there is a definition, you should not redefine it in your code.

18 Editor mode lines and other wordy things there are some editors that can interpret the configuration information embedded in the source file marked by some special tags. For example, emacs can interpret lines marked like this:

-*-mode: C-*-

Or something like this:

/ * Local Variables: compile-command: "gcc-DMAGIC_DEBUG_FLAG foo.c" End: * /

Vim can explain such tags:

/ * vim:set sw=8 noet * /

Do not include any such content in the source code.

Everyone has his own editor configuration, and your source file should not overwrite someone else's configuration. This includes tags about indentation and pattern configuration. People can use their own customized patterns, or use other clever ways to produce the right indentation.

19 inline compilation

In architecture-specific code, you may need to inline assemble links to CPU and platform-related functions. Don't hesitate when you need to do this. However, when C can get the job done, don't use inline assembly for no reason. Where possible, you can and should use C to communicate with the hardware.

Consider writing simple helper functions that bind inline assembly with universal bits (wrap common bits), instead of repeatedly writing inline assembly with minor differences. Remember that inline assembly can use the C parameter.

Large, complex assembly functions should be placed in the .S file and defined in the C header with the corresponding C prototype. The C prototype of the assembly function should use asmlinkage.

You may need to mark the assembly statement as volatile to prevent GCC from removing it without finding any side effects. You don't have to do this all the time, though, this unnecessary action will limit optimization.

When writing a single inline assembly statement that contains multiple instructions, separate each instruction with quotation marks and each line, except for the last instruction, add nt at the end of each instruction so that the next instruction can be correctly indented when assembling output:

Asm ("magic% reg1, # 42\ n\ t"more_magic% reg2,% reg3": / * outputs * /: / * inputs * /: / * clobbers * /)

20 conditional compilation

Whenever possible, do not use preprocessing conditions (# if, # ifdef) in .c files; doing so makes the code harder to read and harder to track logic. The alternative is to provide those .c files with preprocessing conditions in the header file, provide an no-op stub version of # else, and then call those functions (defined in the header file) unconditionally within the .c file. In doing so, the compiler avoids generating any code for calls to the stub function, and the result is the same, but the logic is clearer.

It is best to compile the entire function rather than part of the function or part of the expression. Instead of putting an ifdef in the expression, decompose some or all of the expression, put it into a separate auxiliary function, and apply preprocessing conditions to the auxiliary function.

If you have a function or variable that may become unused in a particular configuration, the compiler warns it that it is defined but not used, marking it as _ _ maybe_unused instead of including it in a preprocessing condition. (however, if a function or variable is always unused, delete it directly.)

In your code, use IS_ENABLED macros whenever possible to convert a Boolean expression marked C by Kconfig and use it in general C conditions:

If (IS_ENABLED (CONFIG_SOMETHING)) {...}

The compiler folds constants and then includes or excludes blocks of code just like you did with # ifdef, so this does not incur any runtime overhead. However, this approach still allows the C compiler to look at the code within the block and check its correctness (syntax, types, symbolic references, etc.). Therefore, if the condition is not met, the reference symbol in the code block does not exist, you still have to use # ifdef.

At the end of any meaningful # if or # ifdef block (more than a few lines), write a comment after the same line of # endif to comment on the conditional expression. For example:

# ifdef CONFIG_SOMETHING. # endif / * CONFIG_SOMETHING * / is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.