Under Linux user space and kernel spatial data exchange Mode, the 1th part of the kernel boot parameters, module parameters and Sysfs, Sysctl, system calls and Netlink__linux

https://www.ibm.com/developerworks/cn/linux/l-kerns-usrs/#ibm-pcon

first, the introduction

In general, the kernel and application have different address spaces on a multitasking system that uses virtual memory technology, so data exchange between the kernel and applications and between applications and applications requires specialized mechanisms for implementation, and it is well known that Inter-process Communication (IPC) mechanism is designed to realize the data exchange between application and application, while most readers may have a better understanding of interprocess communication, there may be little understanding of the data exchange mechanism between the application and the kernel, and this article will describe in detail the various ways in which the Linux kernel and application are exchanged for data. Includes kernel startup parameters, module parameters and Sysfs, Sysctl, System calls, NetLink, Procfs, Seq_file, Debugfs, and RELAYFS. second, kernel boot parameters

Linux provides a way to transfer startup parameters to it by bootloader, which enables kernel developers to transfer data to the kernel to control kernel startup behavior.

The usual way to do this is to define a function that analyzes the parameters and then use the kernel-supplied macro __setup to register it with the kernel, which is defined in linux/init.h, so you must include the header file to use it:

1	__setup ("Para_name=", Parse_func)

Para_name is the parameter name, Parse_func is the function that analyzes the value of the parameter, it is responsible for converting the value of the parameter to the value of the corresponding kernel variable and setting the kernel variable. The kernel provides a function get_option and get_options for the analysis of integer parameter values, which is used to analyze the case that the parameter value is an integer, while the latter is used to analyze a series of integers separated by a comma, and for the case of a string of parameter values, the developer is required to customize the corresponding analytic function. The kernel program in the source code package KERN-BOOT-PARAMS.C illustrates the use of three of cases. The program lists the arguments as an integer, a comma-separated integer string, and a string of three cases. To test the program, the reader needs to copy the program to a directory in the source directory tree of the kernel to be used, in order to avoid confusion with other parts of the kernel, the author recommends creating a new directory under the root directory of the kernel source tree, as Examples, then copy the program to the examples directory and rename it to Setup_example.c, and create a Makefile file for the directory:

1	Obj-y = SETUP_EXAMPLE.O

Makefile only this line is enough, and then you need to modify the source tree root directory of the Makefile file line, put the following line

1	Core-y: = usr/

Modified to

1	Core-y: = usr/examples/

Note: If the reader creates a new directory and the renamed file name differs from the above, you need to modify the location of the Makefile file mentioned above. By doing so, you can build a new kernel in accordance with the kernel build steps, and after you have built the kernel and set up LILO or GRUB as a startup entry for the kernel, you can start the kernel, and then use LILO or grub editing to add the following parameter string to the kernel's startup parameter line:

setup_example_int=1234 setup_example_int_array=100,200,300,400 Setup_example_string=thisisatest

Of course, the parameter string can also be written directly to the kernel command-line argument string in the Lilo or grub configuration file that corresponds to the new kernel. Readers can use other parameter values to test the feature.

The following is the output from the author's system using the above parameter row:

1 2 3 4

setup_example_int=1234 setup_example_int_array=100,200,300,400 Setup_example_int_array includes 4 intergers setup_ Example_string=thisisatest

Readers can use

1	DMESG | grep setup

To view the output of the program. third, module parameters and Sysfs

Kernel subsystems or device drivers can be directly compiled into the kernel, can also be compiled into a module, if compiled into the kernel, you can use the method described in the previous section to pass parameters to them through the kernel boot parameters, if compiled into a module, you can pass the parameter when inserting the module through the command line, or at run time, Set up or read module data by SYSFS.

SYSFS is a memory-based filesystem, and in fact it provides a way to open the kernel data structures, their attributes, and the connection between attributes and data structures to the user state, which is tightly integrated with the Kobject subsystem, based on RAMFS,SYSFS. So the kernel developer does not need to use it directly, but rather the subsystems of the kernel use it. To use SYSFS to read and set kernel parameters, the user can read and set the parameters that the kernel opens to the user through the SYSFS by using a file operation only if the SYSFS is loaded:

1 2	$ mkdir-p/sysfs $ mount-t Sysfs Sysfs/sysfs

Note, do not confuse Sysfs and Sysctl, Sysctl is the kernel of some control parameters, the purpose is to facilitate the user to control the behavior of the kernel, and SYSFS is only the kernel of the Kobject object hierarchy and attributes open to the user view, so the majority of the SYSFS is read-only , the module as a kobject is also exported to the SYSFS, module parameters are exported as module properties, the kernel implementation for the use of the module provides a more flexible way, allowing users to set module parameters in the SYSFS visibility and allow users to write the module when the user set these parameters in the SYSFS , then the user can view and set the module parameters through SYSFS, allowing the user to control the module behavior while the module is running.

For modules, variables declared as static can be set from the command line, but to be visible under SYSFS, you must explicitly declare them by macro Module_param, which has three parameters, the first is the parameter name, the variable name that is already defined, and the second argument is the variable type. Available types are byte, short, ushort, int, uint, long, ulong, charp and bool or invbool, respectively corresponding to type C char, short, unsigned short, int, UN Signed int, long, unsigned long, char * and int, users can also customize type XXX (if the user defines param_get_xxx,param_set_xxx and param_check_xxx). The third parameter of the macro is used to specify access rights, and if 0, the parameter will not appear in the Sysfs file system, allowing access to be a combination of s_irusr, S_iwusr,s_irgrp,s_iwgrp,s_iroth, and S_iwoth, respectively, corresponding to the user-read , user write, user group read, user group write, other user read and other user write, so the access permission setting of file is consistent.

The kernel module MODULE-PARAM-EXAM.C in the source code package is an example of the interaction between user state and kernel state data using module parameters and Sysfs. The module has three parameters that can be set from the command line, and the following is an example of a running result on the author's system:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20-21

$ insmod./module-param-exam.ko my_invisible_int=10 my_visible_int=20 mystring= "Hello,world" My_invisible_int = ten My_v Isible_int = mystring = ' Hello,world ' $ ls/sys/module/module_param_exam/parameters/mystring my_visible_int $ cat/sy S/module/module_param_exam/parameters/mystring Hello,world $ cat/sys/module/module_param_exam/parameters/my_ Visible_int $ echo >/sys/module/module_param_exam/parameters/my_visible_int $ cat/sys/module/module_param_ Exam/parameters/my_visible_int $ echo "abc" >/sys/module/module_param_exam/parameters/mystring $ cat/sys/ Module/module_param_exam/parameters/mystring ABC $ rmmod module_param_exam my_invisible_int = Ten My_visible_int = i string = ' abc '

Four, Sysctl

Sysctl is an effective way for users to set and obtain the configuration parameters of the runtime kernel, in which case the user can change the kernel configuration parameters at any time when the kernel is running, or it can obtain the kernel configuration parameters at any time, usually These configuration parameters of the kernel also appear in the/proc/sys directory of the proc file system, the user application can directly through the file in this directory to implement the kernel configuration of read and write operations , for example, users can

1	Cat/proc/sys/net/ipv4/ip_forward

To know if the kernel IP layer allows IP packets to be forwarded, the user can

1	Echo 1 >/proc/sys/net/ipv4/ip_forward

The kernel IP layer is set to allow forwarding of IP packets, that is, the machine is configured as a router or gateway. In general, all Linux releases also provide a system tool sysctl that can set and read kernel configuration parameters, but the tool relies on the proc file system, and the kernel must support the proc file system in order to use the tool. The following is an example of using the Sysctl tool to get and set kernel configuration parameters:

1 2 3 4 5 6

$ sysctl Net.ipv4.ip_forward net.ipv4.ip_forward = 0 $ sysctl-w net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1 $ sysctl NE T.ipv4.ip_forward Net.ipv4.ip_forward = 1

Note that the parameter net.ipv4.ip_forward is actually converted to the corresponding proc file/proc/sys/net/ipv4/ip_forward, option-W indicates that the kernel configuration parameter is set, there is no option to represent the read kernel configuration parameter, and the user can use the Sysctl-a to read all kernel configuration parameters, for more information on Sysctl tools, please refer to the man page Sysctl (8).

However, the proc file system is not necessary for sysctl, and in the absence of proc file system, it is still possible to use the system call Sysctl provided by the kernel to set up and read the kernel configuration parameters.

A practical example program is given in the source code package, which shows how to use sysctl in kernel and user state. The header file sysctl-exam.h defines the Sysctl entry ID, and the User state application and kernel modules require these IDs to manipulate and register sysctl entries. The kernel module is implemented in file Sysctl-exam-kern.c, in which each SYSCTL entry corresponds to a struct ctl_table structure that defines the ID (field sysctl) of the Ctl_name entry to be registered, in the proc The name below (field procname), the corresponding kernel variable (field data, note that the assignment of the field must be a pointer), the maximum length allowed for the entry (field MaxLen, which is used primarily for string kernel variables so that when the entry is set, A string that exceeds the maximum length is truncated to the back of the extra long portion), the entry's Access rights (field mode) under the proc file system, and the handler function (field Proc_handler, for an integer kernel variable, when passed through the proc setting, should be set to &PROC_ Dointvec, and for string kernel variables, set to &proc_dostring), String handling policy (field strategy, generally this is &sysctl_string).

The SYSCTL entry can be a directory, at which point the Mode field should be set to 0555, otherwise the SYSCTL entry under it will not be accessible through sysctl system calls, and the child points to all entries under the directory entry, and for multiple entries in the same directory, it is not necessary to register one by one. Users can organize them into an array of struct ctl_table types, and then register them once, but at this point the last structure of the array must be set to null , i.e.

1 2 3

{. Ctl_name = 0}

The registered SYSCTL entry uses the function register_sysctl_table (struct ctl_table *, int), the first parameter is the struct entry or entry array pointer for the defined CTL_TABLE SYSCTL structure, The second parameter is the position inserted into the SYSCTL Entry table, and if inserted to the end, it should be 0, or not 0 if inserted to the beginning. The kernel organizes all sysctl entries into sysctl tables.

When the module is unloaded, you need to use the function unregister_sysctl_table (struct Ctl_table_header *) to register SYSCTL entries that are registered through the function register_sysctl_table The function register_sysctl_table returns the structure struct Ctl_table_header when the call succeeds, which is the table header of the Sysctl table, which is used by the registry function to unload the corresponding SYSCTL entry. The user-state application sysctl-exam-user.c through the SYSCTL system to view and set the SYSCTL entries registered by the previous kernel module (of course, if the user's system kernel already supports the proc file system, it can be used directly using file operations such as Cat, Echo, and so on directly view and set these sysctl entries).

The following is an example of the output from the author running the module and application:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16-17

$ insmod./sysctl-exam-kern.ko $ cat/proc/sys/mysysctl/myint 0 $ cat/proc/sys/mysysctl/mystring $/sysctl-exam-user Mys Ysctl.myint = 0 mysysctl.mystring = "" $/sysctl-exam-user "Hello, world" old value:mysysctl.myint = 0 New Value:my Sysctl.myint = vale:mysysctl.mystring = "" "New value:mysysctl.mystring =" Hello, World "$ cat/proc/sys/mysysctl /myint $ cat/proc/sys/mysysctl/mystring Hello, World $

v. System call

System calls are the interfaces that the kernel provides to the application, and most of the operations that apply to the underlying hardware are done by invoking system calls, such as getting and setting the system time, which requires gettimeofday and settimeofday to be called separately. In fact, all system calls involve data exchange between the kernel and the application, such as the file system operation function Read and write, setting and reading the setsockopt and getsockopt of the network protocol stack. Instead of explaining how to add new system calls, this section explains how to use existing system calls to implement user data transfer requirements.

In general, users can create a pseudo device to the application and the core data exchange between the channel, the most common practice is to use a pseudo-character device, the implementation of the method is:

1. Defines the necessary functions for manipulating character devices and sets the structure struct file_operations

Structure struct file_operations is very large, for the general data exchange requirements, only the definition of open, read, write, IOCTL, MMAP and release functions is sufficient, they actually correspond to the user state file system operation function Open, r EAD, write, IOCTL, mmap and close. Examples of the prototypes of these functions are as follows:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

ssize_t exam_read (struct file * file, char __user * buf, size_t count, loff_t * PPOs) {...} ssize_t exam_write (struct fil E * file, const char __user * buf, size_t count, loff_t * PPOs) {...} int exam_ioctl (struct inode * inode, struct file * file, unsigned int cmd, unsigned long argv) {...} int exam_mmap (struct file *, struct vm_area_struct *) {...} int exam _open (struct inode * inode, struct file * file) {...} int exam_release (struct inode * inode, struct file * file) {...}

After defining these action functions, you need to define and set the structure struct file_operations