Basic concepts of process management and terminal drive

First, preface

For any OS, the content of the terminal section is always very painful and frustrating, and so is gnu/linux. The main reasons are two, one is terminal drive and terminal-related system software carries too much content: a variety of virtual terminals, pseudo-terminal, serial communication, modem, printer and so on. The second possibility is that the terminal and signal processing, process relations and other coupling together to increase the difficulty of understanding the terminal drive. The goal of this article is to be able to clarify these things.

In the second chapter, this article will briefly introduce the terminal of some basic knowledge, these knowledge in WOWO Terminal basic concept document also has the description, I repeat here once, deepen impression (hehe, actually this chapter of content wrote a year ago, later suspended, this time reorganize, publish out). The third chapter describes the basic knowledge of the TTY (terminal) related to process management and hopes to help the general public understand the interaction between the process and the terminal driver. The main concepts include: Session, foreground process group, controlling terminal, Job control, and so on. The last chapter describes the concepts of process management and terminal drive related to the actual application scenario.

Ii. basic knowledge of the terminal

This chapter is divided into two sections, the first section describes the concept of the terminal, and other subsections describe a variety of terminal drivers.

1. What is a TTY and what is a terminal?

TTY is the abbreviation of teletype, literal translation into Chinese is the telex typewriter. We are all familiar with the telephone,phone itself as a handset or as a tool for sounding or using sound, and the meaning of tele is that it is far away and needs to be transmitted by means of electrical signals. The same concept can be applied to teletype:type refers to the typing or printing of the body, tele that the typing and printing mechanism is far apart, need to pass the signal through the wire. To understand the concept of teletype need to go back to the past communication era, the original invention is a telegram, the message into Morse code, through the operator will be a long short tone sound sent out, at the receiving end, will also set up an operator, listen to a long short tone tone, restore the message. This kind of communication is very high demand for people, need specialized training to be on duty, this seriously hindered the masses of the masses to exchange information demand, so teletype such a machine was invented, it includes keyboard module, transceiver information module and character print module (some modules are mechanical, so, in modern language, Teletype is also a mechanical electronic device). When you send a message, you need to constantly press the character key, which is automatically sent to the wire. When receiving a message, the receiver can automatically receive the character signal to the end and print out the corresponding character.

The computer system invention is compares the thing which after, certainly is than teletype late. Computer systems require input and output devices, and Teletype includes keyboards and printer, which can be used as input and output devices for computer systems, so Early computers used teletype as terminal equipment (some teletype devices also supported perforated paper tapes as inputs or perforated tape as output). With the development of the computer industry, the teletype device or the perforated mechanism module is replaced by the display. In fact, when Teletype is applied to a computer system, the term TTY (teletype) is no longer applicable (at this time TTY has no traditional communication function, more is a computer system input, that is, computer terminal), So it would be more appropriate to call a TTY a terminal.

The times are always forward, whether you want to or not. In fact, the current young engineers are unlikely to really use the terminal equipment, because it was eliminated. My Computer courses during college were all using a DEC VAX mainframe (mainframe computer), of course, I'm not exclusive, this mainframe is connected to more than 30 terminals, each with a terminal. And the terminal device will receive the keyboard input from each classmate, and send these input through the means of serial communication to the VAX mainframe, VAX large opportunity to process each user's keyboard input and command, then the output is returned and displayed on the screen of each terminal. The terminals are basically text terminal, so the serial communication between the host and the terminal is character-based, and the terminal receives the characters that are displayed on the screen. When entering the computer (microcomputer) era, each host has its own display devices and keyboard equipment (thanks to the development of large-scale integrated circuits), graphic displays are lattice information rather than character-based display, LCD and keyboard is not through the slow serial communication device and the main CPU system connected , from this point of view, we are currently exposed to the terminal is not a real terminal equipment, it should be called "terminal simulation equipment." For example, we can make a terminal by using a window in a Windows system with a keyboard device, and log on to the local computer or to a remote host.

2. What is a virtual terminal (Vsan Terminal)

Although the traditional terminal equipment disappeared with the progress of the times, but we can still through the personal PC graphics display system (SDRAM in the frame buffer plus LCD controller plus display Panel) and keyboard to simulate traditional character terminal equipment (so called virtual terminal equipment). The concept of the entire system is as follows:

Because there is no physical terminal equipment, so vitual terminal can not directly deal with the hardware, it to operate display and keyboard hardware must pass Framebuffer drive and keyboard driver.

Virtual terminal is not the actual physical terminal equipment, the reason is called virtual because it can be in a physical graphics terminal (keyboard plus a monitor) running several virtual terminals simultaneously. Virtual terminals are also known as virtual consoles. For a Linux system, the kernel supports 64 virtual terminals. The user can switch the Virtual Console via ALT+FX. At present, the Gnu/linux operating system supports 6 virtual terminals when booting, the user alt+f1 ~ F6 to switch, ALT+F7 will switch to the GUI environment. Once in the graphical desktop environment, you can cut back to the character interface by ctrl+alt+fx the virtual terminal. For the graphical interface of the terminal-related software architecture diagram we will describe in later chapters.

The main device number of the virtual terminal is 4, the character device, the first 64 devices are Virtual Console devices, the specific secondary device number is assigned as follows:

4 Char TTY devices

0 =/dev/tty0 Current Virtual Console
1 =/dev/tty1 First Virtual Console
...
/dev/tty63 = 63rd Virtual Console

Although the kernel supports 64 virtual terminal devices, whether the entire system supports or depends on the configuration. Generally speaking, the Gnu/linux operating system supports 6 virtual terminals (using TTY1~TTY6) at boot time. A TTY device with a secondary device number equal to 0 is more special, representing the current Virtual Console. If the GUI system is not started, the default tty0 points to Tty1, which can then be toggled according to the user's actions, but in any case, tty0 points to the current virtual terminal.

3, what is the console (consoles)

For Linux systems, the console or the system console is also a terminal device, but it has its peculiarities, as follows:

(1) can support single user mode for login

(2) Receive log messages and alarm messages from the kernel

In a Linux system, we typically set the system console device as one of the virtual terminals (typically the current Vsan, or/dev/tty0), so that we can see the system's message on a virtual terminal. Terminal. In the embedded environment, we will generally set the system console device as a serial terminal or USB serial terminal.

The system console can be set via command line kernel, for example:

root=/dev/mtdblock0 console=ttys2,115200 mem=64m

This allows you to choose a serial device as the system console.

4, what is pseudo terminal (pseudo terminal or pty)

In Linux, pseudo-terminal is unable to through the regular terminal equipment (display and keyboard) login system (such as the host's monitor and keyboard GUI program control, doubts that the host has no monitor and keyboard device, only through the network login), Provides a mechanism for simulating terminal operations, which includes the master and slave two parts. Slave device behaves like a physical terminal device, which is used by processes to read data from Slave device or to write data to Slave device. A terminal is simulated by this method. So why should there be such pseudo-terminal equipment, and why should have the main device and from the device pair it? The following picture can explain:

Of course, most users use a graphical user interface (GUI) system when using the Gnu/linux system, where the entire display and keyboard (that is, traditional virtual terminal equipment) are under the control of a Windows management process. From the perspective of use, the user is generally launched a terminal window program to simulate the command line terminal scene. Users can launch multiple such windows, each of which is a process that receives user input, expects and communicates with the shell through the terminal. But at this time, all the window process is actually unable to open and use Display+key board terminal equipment (GUI management Process Control the actual physical terminal resources), how to do? This will use pseudo-terminal equipment. Each pair of pseudo-terminal devices is connected to a terminal window process and a shell process on the display. When the Windows management process receives a character from the keyboard, the character is sent to the terminal window process that obtains the current focus, and the terminal window process sends the modifier to the corresponding pseudo-terminal "master Device". Therefore, for keyboard input, the window management process plays the role of relay and distribution. The characters written to the "main device" end of the pseudo-terminal immediately reach the "slave" end, where the action is exactly the same as the normal terminal device for the shell process associated with the slave device. The other direction of communication is similar, here will not repeat it.

Of course, and the shell process through the pseudo-terminal connection does not have to be a terminal window process, it may be other processes, such as the network service process, this is the network terminal login scene, and its structure is similar, we can self-brain.

5. Serial Terminal

Serial terminal as if there is nothing to say, we are familiar with, here by the way the serial Terminal device node bar, as follows:

The main device number is the 4 character device is the TTY devices, the virtual terminal occupies the 0~63 minor device number, after the minor is the serial device uses
* =/DEV/TTYS0 First UART serial port
...
255 =/dev/ttys191 192nd UART serial port

The main device number of the USB serial terminal is 188 character device, which is the host side of the USB serial converters devices, specifically as follows:
0 =/dev/ttyusb0 First USB serial converter
1 =/dev/ttyusb1 Second USB Serial Converter
...
The main device number is 127 for the character device is the gadget side of the USB serial devices, as follows:
0 =/dev/ttygs0 First USB serial converter
1 =/dev/ttygs1 Second USB Serial Converter
...

III. process management and terminal-related concepts

1, what is the shell, what is the login system?

If OS kernel is the body of a turtle, then the shell is the shell that protects the turtle's body. The shell provides a user interface to access the OS kernel service, which allows the user to control the operation of the entire system (such as file movement, startup process, stop process, etc.) through the shell. There are two main types of shell, one is familiar with the desktop environment, and the other is based on the text command line type, mainly for the industry personnel use. The command line type of shell requires the user to remember many complex commands and script formats, etc., but it is very efficient and fast. The GUI type of shell is simple to operate, user-friendly, but efficiency is criticized.

As mentioned above, the shell is human access, control computer Services interface, but this interface is some special, the shell itself has its own requirements: the user can not through any device and shell interaction, must be an end device. We are now more advanced network equipment, can be directly through the network equipment and shell communication? No, network equipment is not an end device, want to access the shell through the network device, must pass through the pseudo terminal (later). The shell interacts with humans as follows:

For system engineers, we are more concerned with command line type shell. During the boot process of the system, the INIT process initializes the system according to the settings in the/etc/inittab (in this case the traditional system boot process, if you use SYSTEMD, the startup process will be different, but the concept is similar), and the TTY-related content includes:

1:2345:respawn:/sbin/getty 38400 Tty1
2:23:respawn:/sbin/getty 38400 Tty2
3:23:respawn:/sbin/getty 38400 Tty3
4:23:respawn:/sbin/getty 38400 Tty4
5:23:respawn:/sbin/getty 38400 Tty5
6:23:respawn:/sbin/getty 38400 Tty6

The init process creates 6 Getty processes, six Getty processes listening on Tty1~tty6 Six virtual terminals, waiting for the user to log on. After the user logs in, the specified shell program (for example,/bin/bash) is started based on the user's profile (/etc/passwd). Thus, the shell is actually a command parser that runs on the side of the computing resource and interacts with the TTY driver and the peer-to-side TTY device (which may be a physical terminal or analog).

2. What is Job control

As with terminals, job control's requirements in modern operating systems are not so obvious that many engineers do not know about it and do not understand job control-related concepts. In the past, computers were still relatively rare, and every engineer could not have their own computers, and engineers were using character terminals to log on to computer systems (which, of course, did not have a GUI system) to share common computing resources. In its own terminal interface, the task of a serial execution, there is no possibility of multiple tasks to execute together? (such as running a science-related program in the background, the front desk performs a little game to relax) This is the concept of job control. The job control function is in fact a terminal can support multiple jobs (that is, the process group, described later) control (start, end, front and rear conversion, etc.). Of course, in the introduction of virtual terminals, especially after the popular GUI system, job control needs have been weakened, engineers in a number of task requirements, you can open more virtual terminal, or directly open a few termianl Windows program is OK, but the job Control is a feature of the POSIX standard, so the various operating systems are still willing to obey the POSIX standard, which also makes "historical functions" such as job control still exist in modern operating systems.

If job control is not supported, then after the login, you can interact with the shell through the terminal device, after the execution of job A, the user can interact through the terminal and the process group (that is, job a), and when the execution is complete, the control of the terminal is returned to the shell. Then through the user in the terminal input, can be executed in sequence job B, Job C ... After introducing the job control concept, users can perform various tasks in parallel, i.e. job A, job B, Job C ... can be executed in parallel, of course, the foreground task (job) can only have one, all other tasks are running in the background, the user and the foreground any interaction.

Through the above description, we have learned that, in the user's operation, multiple jobs can be executed in parallel, but only one terminal, and in fact, each running job is eager to interact with the user, and to achieve this goal, in fact, the core to solve the problem is the use of terminal problems:

(1) Who will be handed the input of the terminal?

(2) can each process be output to the terminal?

For the first question, the answer is relatively simple, the user in the terminal input of course is submitted to the front desk job, but those background tasks need terminal input when what to do? Task control is required at this time, and there are several actions involved:

(1) When the background job (which is said to be a background process group) reads access to the terminal, the terminal driver sends a sigttin signal to the corresponding background process group.

(2) All processes of the background process group receive the Sigttin signal will enter the stop state

(3) A shell program that is a parent process can capture the state change of the background process group (wait or waitpid), knowing that it has entered the stopped state

(4) The user can tell the background process group to the foreground through the shell command FG, so that it can interact with the user through the terminal. At this time, the original foreground task is transferred to the background execution.

For input, we strictly qualify a process group as the receiver, but for the output the requirements are not so strict, you can have two options:

(1) Front desk tasks and background tasks can be output to the terminal, of course, we all output, I estimate this time the output screen some confusion, hehe ~ ~ ~

(2) The foreground task can be output, but the background task can not. If a background task has written access to the terminal, the terminal driver sends a sigtout signal to the corresponding background process group.

In addition, in order to support job control, the terminal driver also needs to support signal-related special characters, including:

A) Suspend key (default control-z), corresponding to SIGTSTP signal

b) Quit key (default control-\), corresponding to Sigquit signal

c) Interrupt key (default control-c), corresponding to SIGINT signal,

When the terminal driver receives these special characters entered by the user, it is converted to the corresponding signal and sent to the foreground process Group of the session (which will introduce the term later), if the terminal is the control terminal of the session, of course. Therefore, in order for so many process groups (job) to use the terminal in a reasonable and orderly manner, we need the software module to work together, including:

(1) Shell that supports job control

(2) The terminal driver needs to support job control

(3) The kernel must support the signal of job control

3. What is a process group?

Simply put, the process group is a set of processes, of course, we do not have them together for no reason, there must be a common feature, on the one hand, these processes belong to the same job, the signal from the terminal can be delivered to each member of this process group (for job control). In addition, we can send a signal to a process group via the KILLPG interface. No process is independent and must belong to a process group, and when fork, the process falls into the group of processes to which the creator process belongs, and the parent process can set the process group of the child process before the child process exec. For example, the shell program belongs to process Group A, when the user enters the AAA program fork A new process (the shell created the process, no & symbol, is the foreground process), the AAA process is attributed to process Group A (and shell programs belong to the same process group), the exec AAA, it will be put into a new front process group, their own seclusion behind the scenes. If the user enters AAA &, the entire process is similar to the previous description, except that the shell remains in the foreground process group.

From the above description, many engineers may think that the shell can run a foreground process and any number of background processes at the same time, in fact, the shell is actually a process group (that is, job) to control the foreground and background. Let's give a specific example: a set of command lines entered by the user through the terminal, the commands are piped through, and these commands will form a group of processes, such as the following command:

$ proc1 | Proc2 &
$ PROC3 | proc4 | PROC5

For the first line of command, the shell creates a new background process group, creates two processes Proc1 and PROC2, and puts the two processes into the newly created background process group (no access to the terminal). When the second line of command is executed, the shell creates three processes for PROC3, proc4, and PROC5, and adds the three processes to the shell's newly created foreground process group (which can access the terminal).

How do I identify a process group? The process ID is borrowed to identify the process group. For any group of processes, there is always a first-time promoter, who is actually the initiator of the process group, which we call the leader process of the process group, that is, the process ID equals the process group ID, or we use process The process ID of the leader to be the ID of the processes group. Of course, with the execution of the program, there may be processes joining the process group, or the program executing, exiting the process group, and even if the process group leader process exits, it can still exist Its life cycle is until the last process in the process group terminates, or joins other process groups.

With the Getpgid interface function, we can get the process group ID of a process. With the Setpgid interface function, we can join or create a new process group. Of course, the process group is not created or joined arbitrarily, and a process can only control the group of processes for itself or its child processes. And once the child process executes the EXEC function, its parent process cannot control the process group of the child process through Setpgid. It is also important to note that the process that invokes Setpgid, the process that sets the processes group, and the specified process group must be in one sesssion. The last thing to say is that we cannot modify the process group ID of Session leader according to the POSIX standard.

4. What is a session?

Literally, the session is actually a conversation between the user and the computer, the popular concept is this: you want to use computer resources, of course, you can not casually use, need to convene a meeting, the meeting of the two sides are users and computers, users of their own ideas to tell the computer, The computer receives the user's input and returns the result to the user. In this way, the user and the computer go one after another, interacting continuously until the end of the meeting. How do users and computers interact? The user interacts with the computer through the terminal device and the user interacts on behalf of the computer and the shell process. Each time this user and computer interaction occurs, the operation creates a session to manage the interaction between the user and the computer.

If job control is supported, then the session between the user and the computer can execute multiple jobs in parallel, and the job is actually the abstraction of the process group, so the session is actually a container for the process group. It accommodates a foreground process group (only one) and several background process groups (of course, without a connected control terminal, the session may not have a foreground process group, consisting of several background process groups). There are two scenarios for creating a session:

(1) Once login will form a session (we call the login session, most of the scenes are described in the login session).

(2) The daemon process of the system will be in the respective session (we call it daemon session).

In either case, a new session is created through the SETSID function (note: The process that calls the function cannot be a leader of the process group), and because the session is created, the process becomes the leader of the newly created session. Then, the child processes created by session leader, as well as the process group, belong to that session. Why can't process group leader call Setsid to create a session? We assume that there is no such restriction, process group leader (ID equals a) through setsid to add oneself to another new session, with the session must have a process group, created the sesssion of that process group Leader is the first process group leader in the session, identifying the ID of the newly created process group is a. While the other members of the process group are still in the old session, there is still a process group in the old session, so a member of process Group A, part of the new session, part of the old session, which is not in line with session-process Group2-level topologies. I have to meet this requirement, we usually fork first, then let the parent process exit, after the child process executes setsid,fork, the child process cannot be the process group leader, so the above conditions are met.

As a result, Setsid creates a new session and creates a new process group, which is used to identify the progress ID of the session. The newly created sesssion does not have a control terminal, and if the process that calls Setsid has a control terminal, then after calling Setsid, the new session and the control terminal lose the connection relationship. How do I identify a session? We often use session leader to identify the process ID.

5. Control terminal (controlling terminal)

From the above description, we already know: In order to do job control, we put a number of process groups into the session of the container to control. But how does the user control it? It is necessary to establish a connected pipeline, we refer to the terminal associated with the session as the control terminal, the session first process (session Leader) which is connected to the control terminal is called the control progress (controlling process). The session can have a control terminal, cannot have multiple, of course also can not. And a terminal can only be associated with a session, can not be connected with more than one session.

For login session, the terminal device that we log in is basically the controlling terminal of the session, and the shell program is the leader of the session and the controlling of the session. Process The controlling process concept is mainly used when the terminal device disconnects (for example, the network logon scenario, the cable is unplugged), the terminal driver will send hangup signal to the corresponding session of the controlling process.

Session can have a foreground process group and a number of background process groups (very good understanding, Occupy control terminal is the front desk, no is backstage.) Of course, a foreground process group is not available, for example daemon session). For the front-end process group, jointly occupy the control terminal. Typing CTRL + C at the control terminal to produce a terminating signal (or other special character combinations that can generate a signal) is forwarded to all processes in the foreground process group (which is not submitted to the background process). Although the terminal is controlled by the foreground process group, but through shell, kernel and terminal-driven interaction, the background process group can be pushed into the foreground, that is to say: all sessions within the process group can be used to reuse the controlling terminal.

When creating a session, often there is no controlling terminal, when the session leader open an end device, unless the open to specify the O_noctty, Otherwise the terminal will be called the session of the controlling terminal, of course, the terminal can not be the other session of the controlling terminal, Otherwise, there will be a control terminal corresponding to the two session of the situation occurred. Once the control terminal is owned, the sub-process of session leader inherits the controlling terminal. In addition to the implicit settings described above, the program can be displayed by the IOCTL configuration (tiocsctty) controlling terminal, or through the Tiocnotty to remove the terminal and the session connection, into a normal terminal.

For login session,session leader The connection to the terminal is established and the standard input, output, and error are directed to the terminal. Therefore, we do not need direct access to the control terminal for subsequent normal programs that use the shell, typically direct access to standard inputs, outputs, and errors. If there is a need (such as a program's standard input, the output is redirected), you can access the control terminal by opening the/dev/tty device node (major=5,minor=0), and/dev/tty is the control terminal of the current process.

Iv. Application

1. System initialization

When the system starts, the information for the Swapper process (or the idle process) is organized as follows:

Pid	Pgid	Sid	Tty
0	0	0	NO

The Swapper process creates very many kernel threads during the boot process, and the job control-related information for these kernel threads is as follows:

Pid	Pgid	Sid	Tty
X	0	0	NO

Thus, all kernel threads are in a session, belong to a process group, and as the kernel threads are constantly being created, their process IDs start at 2 and increment continuously. The process ID equals 1 is reserved for the init process, which is the interface to the kernel space to go to user space, and just at the beginning, the INIT process inherits the SID and Pgid of the swapper process, but the INIT process calls SETSID during the boot process. To create a new session and process group, the basic information is as follows:

Pid	Pgid	Sid	Tty
1	1	1	NO

2. Virtual Terminal Login

For Linux,/etc/inittab includes login information, which means that the INIT process needs to perform the fork action on which terminal device and execute the (EXEC) Getty program, so Getty has its own process ID and is a normal process. Not the session leader, nor the process group leader, will call Setsid in the Getty program, create a new session and process group, and The program opens an end device that is passed to it as a parameter (this scenario should be Ttyx), so ttyx this virtual terminal becomes the controlling Terminal,gettty process of the session. Once the terminal device is properly opened, the file descriptor 0, 1, and 2 are directed to the terminal device. After these actions are completed, the user is prompted for login information via standard output (for example, login:). After the user enters the user name, the Getty process has completed its historical mission, and it calls exec to load the login program (PID, Pgid, sid are not changed).

The most important task of the login process is, of course, authentication, and if authentication fails, the login process exits execution, and its parent process (that is, the INIT process) listens for the event and executes the Getty repeatedly. If authentication succeeds, then the login process will fork the child process and execute the shell. At first, the login process and shell process belong to a session, but also belong to the same foreground process group, sharing the same virtual terminal, that is to say, the controlling terminal of two processes is the virtual terminal that the login uses. The shell process is not something in the pool, and eventually it will have to separate itself from the login process. The shell process executes setpgid to create a new process group, and then calls TCSETPGRP to set the process group where the shell is located as the foreground process group.

Note: The above description is based on the Debian 8 system.

2. Shell Execution Command

After the virtual terminal is logged in, we can execute the following command:

#ps –eo Stat,comm,sid,pid,pgid,tty | grep TTY | More

The shell performs this command with the following actions:

After/dev/tty1 completes the login, the system exists two process groups, the foreground process group is the shell, the background process group is login, two process groups belong to a session, all the process control terminals are virtual terminal tty1. After executing the above command, the shell creates 3 processes PS, grep, and more, and puts the three processes into a newly created process group (PS is the process group leader), while pushing the process group to the foreground, the shell itself in seclusion behind the scenes. Once the program executes, the shell in the background receives a signal from the child process and pushes itself to the foreground, waiting for the next command entered by the user.

Let's assume that the user enters the following command:

#ps –eo Stat,comm,sid,pid,pgid,tty | grep TTY | More &

The & symbol is actually a command that executes in the background, and the shell executes the command in a similar way, but does not push the newly established process group to the foreground, and the shell itself is still the foreground process group. Because of the pipe, output information along the path of Ps->grep--->more came to the more process, more process output to the standard output, that is, tty1 this virtual terminal, the tragedy occurred, background process group can not write control terminal, This causes the sigtout to be sent to each process group in the background process group, so that both ps,grep and more go into the stop state. At this time as long as the shell to perform the FG operation, you can put the PS that background process group pushed to the foreground, the virtual Terminal screen will print out the relevant process information.

3. GUI system

Todo (not familiar with GUI system, only temporarily todo, haha)

V. References

1, UNIX advanced environment programming

2. POSIX standard

3. The Linux programming interface-a Linux and UNIX System programming Handbook

Basic concepts of process management and terminal drive