Linux hot-plug UDEV mechanism

Table of Contents

1 daemon process

1.1 Basic characteristics of guardianship

1.2 How to distinguish between daemon process and kernel process

2. Daemon development method (daemon)

2.1 daemon function prototype:

2.2 Daemon process – obtain the system time every 10 seconds and write it to the file

3. The difference between daemon process and background process

Four UDEV configuration files

Introduction:

udev is a device management tool. udev runs as a daemon process and manages device files in the /dev directory by listening to uevents sent by the kernel. udev runs in user space, not kernel space. It can dynamically update device files according to the status of hardware devices in the system, including the creation and deletion of device files. Device files are usually placed in the /dev directory. After using udev, the /dev directory only contains devices that actually exist in the system.

Figure 1: What happens when the application space wants to operate the hardware

one daemon

Linux Daemon is a special process that runs in the background. It is independent of the control terminal and periodically performs some task or waits for some event to occur. It requires no user input to run and provides some kind of service, either to the entire system or to a user program. Most servers in Linux systems are implemented through daemon processes. Common daemon processes include system log process syslogd, web server httpd, mail server sendmail and database servermysqld, etc. .

Daemon process names usually end in d

UDEV daemon, which can dynamically update device files according to the status of hardware devices in the system, including the creation and deletion of device files.

1.1 Basic features of guardianship

  1. It has a long life cycle [optional]. Generally, it starts when the operating system starts and closes when it shuts down.
  2. The daemon process is not associated with the terminal, that is, they do not control the terminal, so when the controlling terminal exits, it will not cause the daemon process to exit.
  3. The daemon runs in the background and does not occupy the terminal. The terminal can execute other commands.
  4. The parent process of a daemon process is the init process. Because its real parent process exits before the child process exits after forking out of the child process, it is an orphan process inherited by init.

The Linux operating system itself has many daemon processes that are executed silently to maintain the daily activities of the system. About 30-50

1.2 How to distinguish between daemon and kernel processes

Use the ps -axj command to view the processes in the system. The parameter a indicates not only the processes of the current user, but also the processes of all other users; the parameter x indicates not only the processes with a controlling terminal, but also all processes without a controlling terminal; the parameter j indicates that the processes related to job control are listed. process.

  1. ppid = 0: Kernel process, started when the system starts, and its life cycle runs through the entire system.
  2. The cmd column name with [] is called the kernel daemon.
  3. The ancestor init: It is also a system daemon process. It is responsible for starting specific system services at each operating level; therefore, the PPID of many processes is init, and it is also responsible for adopting orphan processes.
  4. Ordinary daemons (user set daemons) without [] in their names in the cmd column
  5. Those with -1 in the TPGID column are processes that do not control the terminal, that is, daemon processes.
  6. The names enclosed in [] in the COMMAND column represent kernel threads. These threads are created in the kernel and have no user control code, so there are no program file names and command lines. Names starting with k are usually used to represent Kernel.

2. Daemon development method (daemon)

2.1 daemon function prototype:

#include <unistd.h>
int daemon(int nochdir, int noclose);
  1. nochdir: When it is 0, it means changing the current directory to “/”
  2. noclose: When it is 0, it means redirecting standard input, standard output, and standard error to “/dev/null”
  3. Return value: 0 on success, -1 on failure

2.2 Daemon process-get the system time every 10 seconds and write it to the file

  • 1. Create a daemon process (daemon function)
  • 2. Set the signal processing function (but the process receives the SIGQUIT signal and the process exits)
  • 3. Get the current system time, use asctime and locatime to convert it into a human-readable string, and finally write it to the target file
  • 4. Parameter flag, when receiving the SIGQUIT signal, the flag changes from true to false, and the working part of the process is not executed.
de <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <time.h>
#include <stdio.h>
#include <stdbool.h>
int daemon(int nochdir, int noclose);


//C library function char *asctime(const struct tm *timeptr) returns a pointer to a string, which represents the date and time of the structure struct timeptr.
//C library function struct tm *localtime(const time_t *timer) uses the value of timer to fill the tm structure.
//The value of timer is decomposed into a tm structure and expressed in the local time zone.

/*
struct tm {
  int tm_sec; seconds, range from 0 to 59
  int tm_min; minutes, range from 0 to 59
  int tm_hour; Hour, range from 0 to 23
  int tm_mday; Day of the month, range from 1 to 31
  int tm_mon; month, range from 0 to 11
  int tm_year; number of years since 1900
  int tm_wday; day of the week, range from 0 to 6
  int tm_yday; Day of the year, range from 0 to 365
  int tm_isdst; daylight saving time
};
*/
static bool flag = true;


void handler(int sig)
{
printf("I got a signal %d\
I'm quitting.\
", sig);
flag = false;
}

int main()
{
time_t t;
int fd;
//Create daemon process

if(-1 == daemon(0, 0))
{
printf("daemon error\
");
exit(1);
}
//Set signal processing function
struct sigaction act;
act.sa_handler = handler;
sigemptyset( & amp;act.sa_mask);
act.sa_flags = 0;
if(sigaction(SIGQUIT, & amp;act, NULL))
{
printf("sigaction error.\
");
exit(0);
}
//Process work content

while(flag)
{
fd = open("/home/chen/linux/linux_basics/udev/demo.c", O_WRONLY | O_CREAT | O_APPEND, 0644);
if(fd == -1)
{
printf("open error\
");
}
t = time(0);
char *buf = asctime(localtime( & amp;t));
write(fd, buf, strlen(buf));
close(fd);
sleep(10);
}
return 0;
}

Three differences between daemon processes and background processes

1. The daemon process is not linked to the terminal; the background process can output things to the terminal (hooked to the terminal);

2. The daemon process will not be affected when closing the terminal, and the daemon process will not exit when the terminal exits;

Four UDEV configuration files

The rule file is the most important part of udev and is stored under /etc/udev/rule.d/ by default. All rule files must have the suffix “.rules”. Here’s a simple rule:

KERNEL=="sda", NAME="my_root_disk", MODE="0660"

KERNEL is the matching key, NAME and MODE are the assignment keys. The meaning of this rule is: if there is a device with the kernel name sda, this condition will take effect, and the subsequent assignment will be performed: create a device file named my_root_disk under /dev, and set the permissions of the device file to 0660.

udevadm info –attribute-walk –name=/dev/device name

SUBSYSTEM=="usb", ATTRS{idVendor}=="2a70", ATTRS{idProduct}=="4ee7", MODE="0666"

Match keys for udev rules

  1. ACTION: The behavior of the event (uevent), such as: add (add device), remove (delete device);
  2. KERNEL: Kernel device name, for example: sda, cdrom;
  3. DEVPATH: devpath of the device;
  4. SUBSYSTEM: The subsystem name of the device, for example: the system of sda is block;
  5. BUS: The bus name of the device in devpath, for example: usb;
  6. DRIVER: The device driver name of the device in devpath, for example: ide-cdrom;
  7. ID: The identification number of the device in devpath;
  8. SYSFS{filename}: The contents of the device’s property file “filename” under the device’s devpath;
  9. ENV{key}: environment variable. In a rule, you can set the matching keys of up to five environment variables;
  10. PROGRAM: Call external commands;
  11. RESULT: The return result of the external command PROGRAM.

The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Cloud native entry-level skills treeHomepageOverview 15501 people are learning the system