linuxsystem-callsdevice-driverttyread-write

Linux TTY Operation sequence


In "Advanced programming in the UNIX environment", Figure 18.2 then sequence between user process and actual devive is as follows (from devive to user process):

1- actual device

2- tty device driver

3- tty line dicipline

4- kernerl read, write system calls

5- user process

In another link, https://www.linusakesson.net/programming/tty/, I saw another sequence as follows:

1- actual device

2- device driver

3- tty line discipline

4- tty driver

5- user process

My question is that, does step four in the above link (tty driver), is the same as system call? Or can it be explained more to avoid some ambiguties?


Solution

  • Linux OS has two worlds: the userspace, where your processes live, and where you start your /bin/sh or /bin/bahs (or whatever) and try to talk to some /dev/tty* device. And the kernelspace, which is actually the OS itself performing its uneasy duties.

    System calls are the only way to cross the border between those two. When you submit a read or write syscall, you're leaving your userspace and asking kernelspace to do something on your behalf. In particular, that means that the kernelspace code would run instead of your application (where you called a read or write).

    What exactly kernel would do... well, it depends upon lots of factors. Talking to a serial device is significantly different from talking to a hard drive, for example - and that difference lies at the physical level, at the way nature works. A sane kernel wouldn't dare to handle everything and every little bit on its own; it would rather try to expose a well-defined firm generic interface and let specifics be plugged into it either at the compile time or every run time. Drivers are of that sort too: obeying the kernel requirements, they do incapsulate talking to some particular kind of physical devices, like, for example, serial ports. So at a certain moment, after the kernel jumped in, your read or write would pass it to a driver picked upon by the kernel, and that driver is supposed to actually propagate the signal to the device and reply back.