Communication between user process, terminal and kernel
The user process communicates with the terminal using 3 file descriptors. The terminal is treated like a file in unix (for example /dev/tty
) and also has a file descriptor, major, minor number for the kernel to identify it. Thus, the kernel communicates with the user process through the terminal. Another way of communicating is with system calls, which we all know.
Suppose a user process is waiting for input (example:) enter two numbers: _ _
. When we press keys 1and 2on the keyboard, the keyboard buffer fills up, the device driver associated with the keyboard will identify it and wake up the process in the waiting queue. So how is this data (i.e. 1
and 2
) made available to the user process? I think it will be through the terminal.
Also, what happens if you redirect the output, for example $ ./a.out > file
? I checked with help isatty()
that the process is not associated with any terminal. Then how does the kernel interact with the user process? Let's assume my program requires keyboard input.
source to share
When your program calls an input function like:
nread = read(FILENO_STDIN, buffer, sizeof(buffer));
a "system call" is made to the kernel. This kernel program makes sure that the buffer you passed to it is in your program address space and then copies characters (no more than the size you passed) from the terminal kernel buffer to the buffer you provided and returns to you account those.
It is very likely that if the file descriptor (arg 1) points to an open file - the data is coming from the kernel file system buffer (it may need to be copied from the actual device first).
source to share
The high level answer to your question is that you have
User process <> Kernel <> Terminal Driver
On some systems, the terminal driver may be part of the kernel. On others, it is separate code that runs in kernel mode (exact distinction).
When someone presses a key, it triggers a system interrupt that is handled by the driver. One of two things can happen here, depending on how the kernel reported the driver to behave or how the driver is being implemented.
1) The driver can simply store the keystroke in the buffer; or 2) The driver can notify the kernel every time it presses a key.
The kernel can interact with a process in several ways, depending on the system and how the process has configured the terminal:
1) The kernel cannot do anything with the terminal data until the process calls it. The process provides a buffer, the kernel copies data from its internal buffer (or driver buffer). 2) The kernel can send a software interrupt to a process (like Windows or VMS). In this case, the process has previously provided a buffer for the kernel to copy the data to. 3) The kernel can put an event into a process that the process will have to request.
As far as your section question is concerned, the redirection is completely managed outside the kernel. The application (usually a command line shell) will usually interpret 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.
source to share