Fedora

In the beginning, terminals and telecommunications equipment were always attached to serial ports; that's what they're there for. Quite a lot of features -- SIGINT on ctrl-C, EOF on ctrl-D, timeouts, line-based reading, simple translation, cleanup when the connection closes, etc etc etc -- were added to the serial port device driver to keep them simple to use. Modems and terminals had a fair amount in common, incidentally.

So, any interactive terminal program in UNIX talks to the terminal like a serial port. When you close an xterm or a PUTTY window, you expect things it was running to die with it, yes? Like a dialup teletype session would die when a modem hung up. It's the same thing.

But these days, they don't always have a serial port! Instead of rewriting everything imperfectly every time they created a new and special kind of terminal, they added a "virtual terminal" device to the UNIX standard. It's like a special kind of pipe where, if you write ctrl-C into one end, the other end dies... It has all the other usual features UNIX terminal programs have come to expect -- and should, since it's the same device driver.

Run 'stty' in an xterm -- it will tell you your terminal's "baud rate". Which doesn't matter for virtual terminals, but it's there for historical reasons.

The serial port driver handles things like
...and lots of other things. That's all in the device driver itself.

Using virtual terminals means you can run the exact same interactive program in a local terminal, remote terminal, GUI terminal, serial terminal, or whatever else and expect it to work the exact same way, right down to the weirdest bits of UNIX terminal history. (Try logging into a LINUX terminal as allcaps -- and watch the rest of the text become allcaps when it decides you're running a 6-bit terminal!)

ctrl-C is the only serial-like feature Windows has, and not even for serial ports. Windows actually put that feature inside each program -- but not all programs. Which means ctrl-C only works when it wants to.

When you type ctrl-C, the kernel sends SIGINT to whatever's attached to your terminal. It's not a feature of your shell.

When you type a line and hit enter, the kernel delivers the complete line to whatever program's reading. Programs don't have to assemble each individual keystroke themselves (unless they want to.)

These and much more are features of the serial port device driver, which all interactive terminal programs in UNIX depend on.

Serial ports in UNIX are a complicated topic. Sure, if you want.


Depends what you mean by that.

When you mount something atop of /home/, you see the contents of that partition in it and not what was there before. Sorry for the confusion. Perhaps that was poorly worded.

Thanks a lot first of all Corona688 for being extremely patient with all my queries and answer them as simply as possible. Now I am thinking of starting a new thread about Serial ports, but before that I am asking for some reading material on serial ports and terminal devices. So that when I come back to ask my doubts here they don't need to be quite so noobish and obvious questions.

Any links to some study materials for beginners for this topic would really help. Also if anyone can suggest a good book which contains material on this topic will also be nice.

I am asking here because googling on the topic didn't give me any concrete starting point.

Serial ports maybe complex but I am already interested in how they work . First time coming across a design where a terminal communicates to the kernel through a COM port.

Moderator's Comments:

edit by bakunin: You should indeed start a new thread with this. We try to confine each question/theme to a separate thread so that the knowledge base we are building is easier and better to search for information. I will cut this part out and open a new thread with it. See here: Serial Lines Explained

---------- Post updated at 08:20 PM ---------- Previous update was at 08:17 PM ----------

Could you elaborate on this point further. I mean if no one conformed to a standard how on earth is that standard still surviving. And also why is it there ??

For the same reason why there is a OSI-reference protocol stack which is (almost) nowhere implemented. It is an ideal against which each "real existing implementation" is measured. Even if no implementation fully conforms to it every one is - at least in theory - striving to do so and asymptotically converging towards it.

Take the OSI-reference model for networks as an example: to my knowledge the whole seven layers of it where only once being implemented (in some obscure DEC network stack working under VMS), but every network protocol is compared against it and we say that "IP is a layer-3 protocol", even though TCP/IP was not built with the OSI reference model in mind and in fact - from a theoretical POV - really covers only the layers 3, 4 and 5.

I hope this helps.

bakunin

Politics and marketing.

(I would be happy to discuss this further in person, but this in not an appropriate forum to go into the details of my personal feelings and interpretation of the facts behind this topic.)