Tramp data in Kernel

appearances

The kernel often sees that some functions have many parameters, and these parameters will be at the first level to pass, some of the parameters may only be the deepest level of the function will be used, but has been passed a number of levels, including some of the bool type parameters, such as the following code flow, 6 parameters passed many levels.

Kvm_mips_map_page ()-> Gfn_to_pfn_prot ()-> __gfn_to_pfn_memslot ()->hva_to_pfn ()-> Hva_to_pfn_slow ()

How do you feel about such a code? There is something wrong with such a code. it's called What.

For the passing parameters, the industry has a specific terminology, called tramp data, the standard definition is:

(programming) The Data which is passed via one function to another, and not otherwise used by the.

is there a problem?

Tramp data is a typical code bad taste, which says:

Some code needs to understand the information that is provided by other code that is far away, and it needs to be passed through the intermediate medium.

It brings a typical problem such as hardening the code, making it more difficult to refactor any function in the call chain. Spread information (data/methods/architecture) across different places, and some of them don't care about that information. If you need to declare these itinerant tramp data, it may require some new import, which will contaminate the current name space.

In addition, tramp data of type bool is often used as a parameter in the kernel. The parameter of type bool is also a bad taste, which makes the code less readable. Moreover, too much parameter is a bad taste, many problems, such as the complexity of the function, responsibility is not single, difficult to test and so on. Not specially discussed ~ why appear.

Tramp Data A typical scenario is used to replace global variables, we know that inappropriate global variable is also a bad taste, for global variable refactoring, the easiest way is to use Tramp data, this is easy to understand.

In other scenarios, such as the kernel, some functions are complex, there are long call chains, and information that needs to be understood in the underlying functions is usually passed with such tramp data. if resolved.

The most basic way to handle this is:

At a minimum, you need to ensure that the parameter names passed by each level function are the same, and are readable.

There are also some suggestions, such as using a single example to refactor, but the single case is essentially global data and going back, but in some cases the global variable may be better than tramp data ~

Further processing, may involve the design of the code itself, the emergence of tramp data may indicate that the code in the design of the problem, in theory, neat code requires function of a single responsibility. Functions of a single function, should not have too many parameters, tramp data appear less likely. Low coupling. The dependence of remote code indicates that the coupling is not low. Data declarations and data use as short distances as possible. The level of abstraction is consistent. Personal understanding may imply that the data that is dependent on the function should preferably be at the same level of abstraction.

In the reconstruction theory, it is proposed to reconstruct the method of removing the middleman and extracting the class, the concrete operation needs to be dealt with concretely, the actual operation is much more complicated than the theory. puzzles in the kernel

Like this in the kernel is everywhere, seems to have formed a habit and style, writing new code often refer to the existing code, resulting in the new code is still a lot of such cases.

Look at the previous code flow, in 6 parameters, almost all of the data can be obtained from the VCPU, according to the neat code and the theory of refactoring, for the refactoring of too many parameters, the typical approach is abstract, such as the relevant parameters are abstracted into object transfer, corresponding to the kernel of this case, theoretically, Seemingly passing only one vcpu parameter should be a better choice, but the code simply extracts the various data in the VCPU and passes it over and over.

This is a common phenomenon in the kernel, possibly because it is for better performance. This is probably the best excuse for the kernel code to be less clean code than the user-state program.

The kernel community has also launched a debate about the kernel code clean code, but ultimately no results, so far, the kernel contains tens of thousands of lines of code, has already formed its own code style, can not say that its codes are not clean, may need you to change the angle of view ~

Original address: https://happyseeker.github.io/kernel/2017/01/20/tramp-data-in-kernel.html