CODEWITHSUNDEEP
linuxprocessterminalkernel
debendra nath tiwary
debendra nath tiwary

Reputation: 73

Communication between user process, terminal and kernel

A user process communicates to terminal using 3 file descriptors. The terminal is regarded as file in unix (for example /dev/tty) and also has file descriptor, major, minor number for kernel to identify it. So the kernel communicates with the user process through the terminal. Another way to communicate is through system calls that we all know.

Suppose the user process is waiting for input (example: enter two numbers: _ _). When we press 1 and 2 on the keyboard, the keyboard buffer is filled, the device driver associated with the keyboard will identify it and will wake the process in its wait queue. So how is this data (i.e 1 and 2) made avaliable to the user process? It will be through terminal I guess.

Also what happens if redirect the output, e.g $ ./a.out > file? I have checked using isatty() that the process is not associated with any terminal. Then how will the kernel interact with the user process? Suppose my programm requires some input from keyboard.

Upvotes: 4

Views: 1237

Answers (2)

user3344003
user3344003

Reputation: 21617

The high level answer to your question is that the you have

User process <> Kernel <> Terminal Driver

In some systems the terminal driver may be part of the kernel. On others it is separate code executed in kernel mode (fine distinction).

When someone presses a key, it triggers system interrupt that gets handled by the driver. Here, one of two things can happen, depending upon how the kernel has told the driver to behave or how the driver is implemented.

1) The driver may simply store the keystroke in a buffer; or 2) The driver may notify the kernel each time it gets a keystroke.

The kernel may interact with the process in a number of ways, depending upon the system and how the process has configured the terminal:

1) The kernel may do nothing with the data from the terminal until the process calls for it. The process supplies a buffer, the kernel copies the data from its internal buffer (or the driver's buffer). 2) The kernel may send a software interrupt to the process (e.g., Windows or VMS). In this case the process will have supplied a buffer to the kernel beforehand for its to copy the data to. 3) The kernel may queue an event to the process that the process will have to query.

In regard your section question, redirection is managed entirely outside the kernel. An application (usually a command line shell) usually interprets this

  ./a.out > file

by

1) Open FILE.
2) Create a new process where the standard output is the handle to FILE.
3) Run a.out in that process.

Upvotes: 0

John Hascall
John Hascall

Reputation: 9416

When your program calls an input function, for example:

nread = read(FILENO_STDIN, buffer, sizeof(buffer));

a "system call" is made into the kernel. This kernel routine makes sure the buffer you passed to it is in your program's address space and then copies the characters (no more than the size you passed in) from the terminal device's kernel buffer into the buffer you supplied and returns to you the count of those.

A very similar thing happens if the file descriptor (arg 1) points at an open file -- the data comes from the file system's kernel buffer (possibly it needs to be copied from the actual device to there first).

Upvotes: 1

Related Questions