kernel_joe: (Default)
[personal profile] kernel_joe
Termios

According to Single UNIX Specification Version 2 Ц General Terminal Interface (termios.h their structures, functions and constants) defines the way to deal with termios Terminal Structure. The main purpose of public part of specification is to provide set of constants to manage the terminal, i.e. on which codes and how terminal must answers. The private part (how driver must collect data, input and output queues, synchronization) is free to interpretation. Most common set of flags constants covers POSIX, BSD and XOPEN vision of the matter.

In other words the main purpose of Terminal Interface is to convert characters on input and output streams from symbols to device interpretable commands. The main conversion logic is concentrated in *read* and *write* subroutines of terminal driver.

The termios service (I mean *ioctl*) handler codes are also free to implementation but in general there are some *standard* codes used in BSD and System V like systems, and thereby software relays on that implementations.

Line disciplines

As was mentioned above - one of the main purpose (besides unification of dealing with character input/output human devices) of terminal interface is to convert data streams (e.g. when we recognize " " in *write* stream we must send to message to display part of terminal "carriage return" and "new line" commands. Besides *read* and *write* routines alongside of them are *open*, *close* and *ioctl* operation that also may have some not-traditional logic for certain conversion mode. That conversion layers calls Line Disciplines. Thus line discipline is a set of terminal driver handler on of them can be chosen for fixed termios instance.

Custom Line discipline (besides) is used to handle conversion modes e.g. for standard TTY, MOUSE, PPP, SLIP protocols. Many variants of those protocols can be obtained and used in one application. On most Unix-like OS Termios structure has c_line field used to select line discipline.

Teletype Discipline

Teletype driver consists of standard conversion logic (*read* and *write* subroutines) the service logic (*ioct*, handler codes). This means exact the discipline - standard tty discipline used in most cased when used terminal subsystem. E.g. it is used in conjunction with device drivers, like pty, com, ppp, slip, and may others. Teletype driver is not working with devices directly it just converts char from raw to canonical form.

Terminal Drivers

The most wide known variants of tty drivers are pty master/slave drivers and serial line drivers. Other using of tty is covering by ppp, slip and others communication stacks. The terminal driver is responsible to handle the control characters in stream and convert it to device commands, control of it sending to device along with input/output character stream to device.

In theory each terminal driver can use their own discipline or set of disciplines along with providing no discipline. If the terminal driver provides no discipline - the common Teletype Discipline is using. From other side one discipline can be used with two or more teletype driver. I.e. discipline is not connected directly "one to one" with device type. Also terminal can always use teletype discipline as wide known discipline.

Line disciplines are distensible

I.e. you could implement your own line discipline and use it in you application or terminal drivers. For example there is no need to implement all possible and used in industry line disciplines - but must be an elegant way to extend them. Thus discipline is loadable module that can be obtained by its name.

The main teletype discipline is one of the always known disciplines when working with terminal is needed and is responsible for storing information about other disciplines and their using.

             Module 1  Module 2  Module 3
+---------+  +------+  +------+  +------+
| DISCIPL |  | TTY  |  | PPP  |  | SLIP |
| MANAGER |  | DISC |  | DISC |  | DISC |
+---------+  +------+  +------+  +------+


That means that TTY discipline module is not like other discipline module - it is main - and hosts discipline array structure. TTY discipline is some kind of master discipline. Let us see examples on how disciplines are used in TTY stack.

Example 1. RS232 Driver - the same is PTY driver

+-----------+
| USER APP  |
+-----------+
     V
----------+  +-------------+
| COM     |->| TTY         |
| DRIVER  |<-| DISCIPLINE  |
+---------+  +-------------+
     V
+-----------+
| HARDWARE  |
+-----------+



Example 2. PPP Driver

+---------------------+
| PPP client User App |
+---------------------+
    |
    V
+----------------+ +--------+   +----------------+   
| PPP DISCIPLINE | | PPP    |<- | TTY DISCIPLINE |
+----------------+ | DRIVER |-> +----------------+ 
                   +--------+           |
                                        |
                             +----------+------------+ 
                             V          V            V
                         +--------+ +--------+ +--------+ 
                         | COM    | | USB    | | NET    |
                         | DRIVER | | DRIVER | | DRIVER |
                         +--------+ +--------+ +--------+


For example I can (from user app) say to PPP driver not to use PPP discipline but instead your own implemented TEST Discipline. The mechanism of selection underlying hardware is of scope of work of Network Team. TTY subsystem just must provide proper mechanism to using with tty disciplines for authors of PPP driver.

             +-----------------+
+--------+-> | TEST DISCIPLINE |
| PPP    | <-+-----------------+ 
| DRIVER |-> +----------------+
+--------+ <-| TTY DISCIPLINE |
             +----------------+


This can be done by changing c_line flag in termios structure associated with opened file device.

But that can't guaranteed that all drivers must handle that. E.g. in PPP driver is used two disciplines one can be substained but second is always tty. You could change just one discipline by the termios interface. But driver can use more than one discipline in its conversion logic.