Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

The details are hidden in a set of macros designed to conceal the syntactical tedium of adding section attributes (and other attributes) to a portion of object code. The objective is to build a static list of string literals associated with function pointers. This list is emitted by the compiler in a separately named ELF section in the final vmlinux ELF image. It is important to understand this technique; it is used in several places within the kernel for special-purpose processing.

Let's now examine how this is done for the __setup macro case. Listing 5-5 is a portion of code from the header file .../include/linux/init.h defining the __setup family of macros.

Listing 5-5. Family of __setup Macro Definitions from init.h

...

#define __setup_param(str, unique_id, fn, early) \

static char __setup_str_##unique_id[] __initdata = str; \

static struct obs_kernel_param __setup_##unique_id \

__attribute_used__ \

__attribute__((__section__(".init.setup"))) \

__attribute__((aligned((sizeof(long))))) \

= { __setup_str_##unique_id, fn, early }

#define __setup_null_param(str, unique_id) \

__setup_param(str, unique_id, NULL, 0)

#define __setup(str, fn\

__setup_param(str, fn, fn, 0)

...

Listing 5-5 is the author's definition of syntactical tedium! Recall from Listing 5-4 that our invocation of the original __setup macro looked like this:

__setup("console=", console_setup);

With some slight simplification, here is what the compiler's preprocessor produces after macro expansion:

static char __setup_str_console_setup[] __initdata = "console=";

static struct obs_kernel_param __setup_console_setup \

__attribute__((__section__(".init.setup"))) = {__setup_str_console_setup, console_setup, 0};

To make this more readable, we have split the second and third lines, as indicated by the UNIX line-continuation character \.

We have intentionally left out two compiler attributes whose description does not add any insight to this discussion. Briefly, the __attribute_used__ (itself a macro hiding further syntactical tedium) tells the compiler to emit the function or variable, even if the optimizer determines that it is unused. [43] Normally, the compiler will complain if a variable is defined static and never referenced in the compilation unit. Because these variables are not explicitly referenced, the warning would be emitted without this directive. The __attribute__ (aligned) tells the compiler to align the structures on a specific boundary, in this case sizeof(long).

What we have left after simplification is the heart of the mechanism. First, the compiler generates an array of characters called __setup_str_console_ setup[] initialized to contain the string console= . Next, the compiler generates a structure that contains three members: a pointer to the kernel command line string (the array just declared), the pointer to the setup function itself, and a simple flag. The key to the magic here is the section attribute attached to the structure. This attribute instructs the compiler to emit this structure into a special section within the ELF object module, called .init.setup. During the link stage, all the structures defined using the __setup macro are collected and placed into this .init .setup section, in effect creating an array of these structures. Listing 5-6, a snippet from .../init/main.c, shows how this data is accessed and used.

Listing 5-6. Kernel Command Line Processing

1 extern struct obs_kernel_param __setup_start[], __setup_end[];

2

3 static int __init obsolete_checksetup(char *line)

4 {

5 struct obs_kernel_param *p;

6

7 p = __setup_start;

8 do {

9 int n = strlen(p->str);

10 if (!strncmp(line, p->str, n)) {

11 if (p->early) {

12 /* Already done in parse_early_param? (Needs

13 * exact match on param part) */

14 if (line[n] == '\0' || line[n] == '=')

15 return 1;

16 } else if (!p->setup_func) {

17 printk(KERN_WARNING "Parameter %s is obsolete,"

18 " ignored\n", p->str);

19 return 1;

20 } else if (p->setup_func(line + n))

21 return 1;

22 }

23 p++;

24 } while (p < __setup_end);

25 return 0;

26 }

Examination of this code should be fairly straightforward, with a couple of explanations. The function is called with a single command line argument, parsed elsewhere within main.c. In the example we've been discussing, line would point to the string console=ttyS0, 115200, which is one component from the kernel command line. The two external structure pointers __setup_start and __setup_end are defined in a linker script file, not in a C source or header file. These labels mark the start and end of the array of obs_kernel_param structures that were placed in the .init.setup section of the object file.

The code in Listing 5-6 scans all these structures via the pointer p to find a match for this particular kernel command line parameter. In this case, the code is searching for the string console= and finds a match. From the relevant structure, the function pointer element returns a pointer to the console_setup() function, which is called with the balance of the parameter (the string ttyS0, 115200) as its only argument. This process is repeated for every element in the kernel command line until the kernel command line has been completely exhausted.

The technique just described, collecting objects into lists in uniquely named ELF sections, is used in many places in the kernel. Another example of this technique is the use of the __init family of macros to place one-time initialization routines into a common section in the object file. Its cousin __initdata, used to mark one-time-use data items, is used by the __setup macro. Functions and data marked as initialization using these macros are collected into a specially named ELF section. Later, after these one-time initialization functions and data objects have been used, the kernel frees the memory occupied by these items. You might have seen the familiar kernel message near the final part of the boot process saying, "Freeing init memory: 296K." Your mileage may vary, but a third of a megabyte is well worth the effort of using the __init family of macros. This is exactly the purpose of the __initdata macro in the earlier declaration of __setup_str_console_setup[].

You might have been wondering about the use of symbol names preceded with obsolete_. This is because the kernel developers are replacing the kernel command line processing mechanism with a more generic mechanism for registering both boot time and loadable module parameters. At the present time, hundreds of parameters are declared with the __setup macro. However, new development is expected to use the family of functions defined by the kernel header file .../include/linux/moduleparam.h, most notably, the family of module_param* macros. These are explained in more detail in Chapter 8, "Device Driver Basics," when we introduce device drivers.

The new mechanism maintains backward compatibility by including an unknown function pointer argument in the parsing routine. Thus, parameters that are unknown to the module_param* infrastructure are considered unknown, and the processing falls back to the old mechanism under control of the developer. This is easily understood by examining the well-written code in .../kernel/params.c and the parse_args() calls in .../init/main.c.