Yes, if the "CPU" you refer to is meant in a broader sense, like on the IBM-mainframes of the /360 architecture and its successors (/370, /390 and z/OS). In the narrower sense, where "CPU" refers to the processor itself, you don't communicate with it, but with the OS, which in turn manages every resource, including the processor (but also RAM, disks, ...).

Can someone explain how serial ports can be used for session control in a little more detail ?

Because it is a powerful concept. When we talk about "serial lines" we basically say so because of the historic origins where these connections were indeed realised in physical RS232-connections. But in fact we talk about a "bidirectional connection" which was once realised using RS232 connections but also network connections (virtual channels using TCP as transport medium, like in telnet, rlogin and so on, up to modern SSL-socket connections), USB, IRDA, BlueTooth, ...

Counterquestion: what would you like to use instead? If it some sort of bidirectional connection again, you could as well stick with the old TTY-mechanism because you will not be able to enhance that very much. If you want some connection capable of transmitting graphics primitives: this is already there, it is called the X protocol (port 7000) and used to remotely display X-clients over the network on remote X-servers.

One big drawback of this way of connecting terminals with the main system is that management of the terminals is centralised in interrupt-service-routines in the OS. You move the cursor on a remote terminal and basically the main processor receives an interrupt, handles the cursor movement and only then resumes its main work. Connect a real big number of terminals to a UNIX system (say, several thousands) and you can bring it to its knees without the connected users even doing anything worthwile.

If you now envision a way of connecting terminals with some local intelligence so that the main system isn't bothered with load: congrats, this already exists: its the Frontend-Processors and Cluster-Controllers of the SNA network of an IBM mainframe. This is why a z/OS host can serve several thousand user sessions in parallel without problems: the de-centralised 37x5-units and the 3174 cluster controllers make short batch-like jobs from the user input, which the system works off and immediately "forgets" about the session until the next "batch-job" comes along. On the downside, this makes interactive use a bit cumbersome. To scroll down a page in a text you would enter the command for "one page down", then press the "send"-key, now the cluster controller picks your session and the command up, creates the mentioned batch job, the main units sends the result (the next page), the cluster controller creates you new screen content and now you can resume your session and enter whatever on the screen until you hit "send" again, ...

So, coming back to midrange systems: without using decentralised session management like on the mainframe systems, which solves several problems but creates others, we have a system that is as well defined and feasible as it gets. Comparing it to an OS where this well-defined system is not in place (like Windows) we see there is no defined "terminal" device but a directly managed "screen", "keyboard", etc.. You won't notice the difference as long as you have a single PC running the OS, but once you try to work locally and remotely at the same time on the same system simultanuously you will notice that in UNIX/Linux you just create another TTY (maybe over a network session using telnet/rlogin/ssh/whatever, while in Windows?? A remote session in UNIX means some bytes over the network, a Windows remote desktop is simply not possible without a high-speed connection. I can easily connect from home over a secured SSL-connection to a UNIX-system at the office even if the internet connection is bad (like in using my GSM-mobile as access point). Given the bandwidth of such a connection a remote desktop is not even thinkable.

Counterquestion: why not? The way the TTYs in UNIX work everything, from real serial lines to virtual network connections of all sorts is covered. Why remove the support for real serial lines? What would be the gain when stty wouldn't display the Baud rate any more?

What do you mean by "forcefully"? Nobody forces you to use it. Write your own driver for your own sort of terminal (or whatever you want to reaplace the commandline interface with) and if it is of any use perhaps people will start to use it. In the long run feasibility rules and whatever is useful is used.

I hope this helps.

bakunin