Fedora

What are you talking about ??

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.

No current Linux system meets POSIX requirements for OS or utilities behavior. On a POSIX conforming system, you never have to give a --posix option to make a utility behave as specified by the POSIX standard. On a POSIX conforming system, the command:

Code:

echo -n abc

will write the characters -n abc and a trailing <newline> character to standard output.

On a POSIX conforming system, each thread in a process shares a single process ID; on a Linux system each thread gets its own process ID.

There are hundreds of places where Linux systems do not conform to POSIX standard requirements. Fortunately, for a lot of the stuff you run into in daily run-of-the-mill programming, they are quite similar. But, if you try write portable code that will work on any POSIX system (and all UNIX branded systems are POSIX conforming systems and have to also meet additional requirements) there is no guarantee that it will run on a Linux system. (Of course no test suite is perfect, so a UNIX or POSIX branded system may have bugs that haven't been caught yet; but vendors of these branded systems once notified that a conformance bug is present have a contractual obligation to fix it within 6 months or lose their right to use the brand.)

As the POSIX standards evolve, they are picking up some new features from Linux systems. And, over time, many GNU Utilities are coming closer to meeting POSIX requirements. But, for the foreseeable future, Linux systems are most definitely not POSIX conforming systems and cannot be branded as UNIX systems or POSIX systems even if one of the Linux distro vendors was willing to pay the certification costs and fill out all of the paperwork involved.

There is also a standard for Linux systems (the Linux Standard Base AKA LSB), but the last I heard, no Linux system has ever conformed to any version of the LSB either.

Most of your criticisms are quite true! But this one hasn't been true for 10 years. The old threading model -- which amounted to cloned processes sharing the same memory segments -- got thrown out when someone found a big design flaw, they replaced it with NPTL. That means "native POSIX threading library". I expect that's a fair bit closer to compliance.

I expect it would be quite a lot easier for an OS to become POSIX compliant if the tests were easier to get.

Thanks for letting me know. I said: many GNU Utilities are coming closer to meeting POSIX requirements.
I should have said: many GNU Utilities, Linux libraries, and the Linux kernel are coming closer to meeting POSIX requirements.

Surprisingly enough, the vendors who fund the development and maintenance of the UNIX and POSIX conformance test suites so that their systems can be branded or certified haven't accepted the idea that they should give away the test suites so their competitors in the open source community will have an easier time putting them out of business. Nonetheless, I believe some Linux distro vendors do occasionally pay The Open Group to run the tests for them to see what areas still need work to actually become POSIX certified or UNIX branded. Certification or branding will happen some day, but we aren't there yet.

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