January 29, 2011 at 21:11Brief introduction to terminals and console
Dragons live here and there are no menters (instead of an epigraph).
A very concise combat description of “what is a pseudo-terminal” and “console”.
So, firstly, let's determine what a console is: a console is a program that receives buttons from the user, and letters from the screen and specials from the connection to the computer. commands for drawing pictures on the screen.
The terminal is a generalized name for both a program and a special piece of hardware (there are no more such ones in nature). A special exception is when you start a putti or someone else to connect to the serial port of a switch / router / modem (or even a server), then you act (more precisely, the computer with the putti acts) as a terminal (the name "terminal" - because it terminates cable (that is, hanging at the very end)).
As you can easily understand by cable, there are two ends: the terminal and the fact that it sends bytes to the cable.
When the shell starts up, it gets at its disposal a virtual device / dev / tty, which each process has its own - this is the “reverse” part of the terminal. The front part in the case of a cable is implemented by putti + computer, in the case of a computer console, by a specialized kernel driver (virtual consoles). Important: the driver emulates the presence of the terminal.
There is a unix98 interface (/ dev / ptmx), which allows you to create a couple of "input and output" for all applications that apply. In this case, one half represents the “back” half, and the second is the console. It is used, in particular, by openssh and x terminals.
There is a lot of confusion in this place, but the rule is simple: on the one hand, the one who draws, on the other - the one who says what to draw. On the side with which they draw, the user with the keyboard is on the same side. His data goes to the opposite side to the program.
The most frequent program from the “program” side is getty of various types (mgetty, atetty, etc.), the task of which is to set the speed of the channel and run the login command to enter the password.
The front part (drawing bytes) is either a virtual Linux console, or a terminal program (almost any), or a terminal located behind a serial cord (for example, another computer).
Each drawing device (terminal, virtual console, etc.) has its own set of capabilities (supported characters and commands). The terminal type is set by the TERM variable, but only in the sense that it tells the programs which terminal they work with. It is impossible for the TERM variable to force the terminal to emulate other terminals - it knows nothing about this variable.
Sudden application: KVM, XEN (and I'm not sure, but it seems OpenVZ) use this mechanism to access the console of virtual machines: a specialized device is created in the virtual machine that interacts with the daemon in dom0. From the point of view of domU - it has a serial device for the terminal. In order to see the login line on this device, you need to register the line with the getty call in inittab and enable the login (/ etc / securetty).
In dom0, the daemon sees the serial device from domU, creates the corresponding pseudo-terminal using / dev / ptmx). Created devices for connecting terminals appear in / dev / pts / *. In addition, consoled writes to xenstore which domain corresponds to which, specialized terminal machines (xenconsole) can read and execute this. When the xl console (xm console) command is given, it just calls xenconsole with the given parameter.
Instead of xenconsoled, you can use any other terminalka - at least minicom, at least cu, at least socat, at least putty. After connecting to the console, it is correct to set the type of console used (set TERM = linux or set TERM = xterm, installation in vt100 will give a black and white screen).
Exactly the same way you can organize a connection to the machine by modem (if anyone else remembers them) - modems simply "extend" the serial port by N kilometers. On the one hand, you need to configure the modem to answer automatically and hang up mgetty (and don’t forget about / etc / securetty), on the other hand, you need to dial a number and get a regular login message.
It was very concise and which description of pseudo-terminals. Complete is almost impossible, because for a complete understanding of how it works you need to start with teletypes and devices of mechanical typewriters.
The main point that needs to be realized is that tty always has two participants, one of which can draw (itself, or throwing the contents on the screen so that the user terminal draws it), and the other gives commands to draw and accepts sequences button presses.
Main reading material: tldp.org/HOWTO/Text-Terminal-HOWTO.html
A very concise combat description of “what is a pseudo-terminal” and “console”.
So, firstly, let's determine what a console is: a console is a program that receives buttons from the user, and letters from the screen and specials from the connection to the computer. commands for drawing pictures on the screen.
The terminal is a generalized name for both a program and a special piece of hardware (there are no more such ones in nature). A special exception is when you start a putti or someone else to connect to the serial port of a switch / router / modem (or even a server), then you act (more precisely, the computer with the putti acts) as a terminal (the name "terminal" - because it terminates cable (that is, hanging at the very end)).
As you can easily understand by cable, there are two ends: the terminal and the fact that it sends bytes to the cable.
When the shell starts up, it gets at its disposal a virtual device / dev / tty, which each process has its own - this is the “reverse” part of the terminal. The front part in the case of a cable is implemented by putti + computer, in the case of a computer console, by a specialized kernel driver (virtual consoles). Important: the driver emulates the presence of the terminal.
There is a unix98 interface (/ dev / ptmx), which allows you to create a couple of "input and output" for all applications that apply. In this case, one half represents the “back” half, and the second is the console. It is used, in particular, by openssh and x terminals.
There is a lot of confusion in this place, but the rule is simple: on the one hand, the one who draws, on the other - the one who says what to draw. On the side with which they draw, the user with the keyboard is on the same side. His data goes to the opposite side to the program.
The most frequent program from the “program” side is getty of various types (mgetty, atetty, etc.), the task of which is to set the speed of the channel and run the login command to enter the password.
The front part (drawing bytes) is either a virtual Linux console, or a terminal program (almost any), or a terminal located behind a serial cord (for example, another computer).
Each drawing device (terminal, virtual console, etc.) has its own set of capabilities (supported characters and commands). The terminal type is set by the TERM variable, but only in the sense that it tells the programs which terminal they work with. It is impossible for the TERM variable to force the terminal to emulate other terminals - it knows nothing about this variable.
Sudden application: KVM, XEN (and I'm not sure, but it seems OpenVZ) use this mechanism to access the console of virtual machines: a specialized device is created in the virtual machine that interacts with the daemon in dom0. From the point of view of domU - it has a serial device for the terminal. In order to see the login line on this device, you need to register the line with the getty call in inittab and enable the login (/ etc / securetty).
In dom0, the daemon sees the serial device from domU, creates the corresponding pseudo-terminal using / dev / ptmx). Created devices for connecting terminals appear in / dev / pts / *. In addition, consoled writes to xenstore which domain corresponds to which, specialized terminal machines (xenconsole) can read and execute this. When the xl console (xm console) command is given, it just calls xenconsole with the given parameter.
Instead of xenconsoled, you can use any other terminalka - at least minicom, at least cu, at least socat, at least putty. After connecting to the console, it is correct to set the type of console used (set TERM = linux or set TERM = xterm, installation in vt100 will give a black and white screen).
Exactly the same way you can organize a connection to the machine by modem (if anyone else remembers them) - modems simply "extend" the serial port by N kilometers. On the one hand, you need to configure the modem to answer automatically and hang up mgetty (and don’t forget about / etc / securetty), on the other hand, you need to dial a number and get a regular login message.
It was very concise and which description of pseudo-terminals. Complete is almost impossible, because for a complete understanding of how it works you need to start with teletypes and devices of mechanical typewriters.
The main point that needs to be realized is that tty always has two participants, one of which can draw (itself, or throwing the contents on the screen so that the user terminal draws it), and the other gives commands to draw and accepts sequences button presses.
Main reading material: tldp.org/HOWTO/Text-Terminal-HOWTO.html