Hacker News Reader

Comment by Animats | Hacker News Reader

For historical reasons, UNIX and Linux handle the line discipline and echoing in the kernel. But really, that should be done in a user-space program. Something like xterm, but without X. The kernel should just handle the serial port hardware.

Is serial port login even enabled by default any more on Linux?

View on HN

> Is serial port login even enabled by default any more on Linux?

Yes. systemd even provides it automatically if the kernel's console is configured to be a serial port terminal.

* http://askubuntu.com/a/621209/43344

* http://unix.stackexchange.com/a/194218/5132

In nosh, one simply enables/starts a serial GeTTY service such as mgetty@ttyS1 . There's an example of what such a run script would look like in the "Terminals" chapter of the nosh Guide. It's 2 lines long.

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

I agree it should be done in user space, but how? Surely requiring every program to use something like GNU readline is a bad idea? I vaguely remember reading somewhere that Plan 9 does this well. Does anyone know how, or know another OS that does it well? I also vaguely remember one of my textbooks mentioning something called STREAMS from System V. Anyone know anything about it?

In QNX, the serial console, if present, is managed by a driver in user space, loaded with the kernel as part of the boot image. That's how all initial drivers in QNX start up. For embedded systems, the serial console driver might not be loaded, or could be a special-purpose driver for the hardware. The user mode driver is used for any messages during boot; there's no special startup-time kernel driver.

The boot image may be in ROM, and on small embedded devices, it usually is. For QNX, disks and file systems are optional. If disk support is desired, some disk drivers and an init program are included in the boot image, and the later phases of startup are somewhat UNIX-like.

It's possible to build a QNX boot image so that networking comes up before the file system, which is useful for headless embedded systems. It's also possible to build a classic system for x86-type BIOS-controlled boot from disk, and run QNX on the desktop, but that's not done much any more.

How realistic is this on a monolithic kernel like Linux, though? On QNX all drivers - not just the serial ports - are in user-space. QNX has a microkernel.

User-space drivers on Linux are always a special case - like FUSE. Someone always has to write bespoke infrastructure to make it happen.

Linux has, over the years, acquired many of the features of QNX - interprocess communication, real-time scheduling, user mode drivers, user mode file systems, etc. But all the old in-kernel stuff remains, resulting in a huge, bloated kernel with a huge attack surface.

(If only QNX, the company, weren't so screwed up. They were sold twice, once to Harmon (car stereos) and once to Blackberry. They went open source, closed source, open source, and closed source again. Most developers got fed up and went to other platforms. QNX powers most of Boston Dynamics's robots; when you need coordinated control of all those actuators at 1KHz, you need something at least as good as QNX.)

> Surely requiring every program to use something like GNU readline is a bad idea?

Moving the line discipline out of kernel mode into application mode does not necessitate that every program have an individual copy of the code. As already pointed out, in operating systems that do this the line discipline analogue is encapsulated within a daemon that presents the terminal character devices (or analogues thereto) to the rest of the system. The programs using the terminal think that they are talking to a terminal device in the ordinary (usually, but not necessarily) POSIX-General-Terminal-Interface-like way. As mentioned, in the Hurd this daemon is the /hurd/term daemon. In Windows NT it is the CSRSS daemon, or a CONHOST.

> Surely requiring every program to use something like GNU readline is a bad idea?

That's basically how it works now. Kernel's line discipline is awful and nobody wants to use it so they build with readline or something equivalent.

You'll notice a program is using the line discipline when the arrow keys print weird characters instead of working cor rectly, rlwrap has been invented for those programs.

The clean/logical/plan9-style solution is having the terminal implement line editing. But that alone would preclude autocompletion and history search from working.

Wrong side of the tty in my opinion. Everything that is done by tty should be done by the terminal, except generating signals from keyboard input (because that needs to happen on the same machine as the controlling process).

Only reason its in the kernel is that you couldn't patch a VT-100. Virtual terminals are a lot easier to extend than a web browser, and yet they haven't seen a widely adopted extension in more than 20 years.

Working on it. :-)

> I agree it should be done in user space, but how? Surely requiring every program to use something like GNU readline is a bad idea?

Not full readline, but libtinfo, or a similar library that reads a terminfo database. And the standard C library could handle this by default for "cooked" input devices.

I find this idea not very attractive. That means any program that reads from stdin has a dependency on some random database. Even cat, or grep. (You could argue that grep needs this anyway to color things, but still.)

Not every program that reads from stdin, just every program that wants stdin from a "cooked" TTY. Many programs can just perform raw reads.

Hurd has a console server.

The line discipline analogue isn't in the console daemon. It's in the term daemon.

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/hu...

You are the first person I've seen to ever include the rightmost dot in the domain name in a comment on the internet!

> Is serial port login even enabled by default any more on Linux?

That's a distribution choice, but often not. Last I checked on a Debian system, it was just a matter of uncommenting the getty on /dev/ttyS0 in /etc/inittab. Dunno how it's done with systemd nowadays.

  systemctl enable serial-getty@ttyS0.service
  systemctl start serial-getty@ttyS0.service

Alternatively, add to kernel command line:

  console=ttyS0

kmscon is userspace replacement for linux kernel console.

You missed out "a". kmscon is a replacement.

* http://unix.stackexchange.com/a/177209/5132

As you can see, it followed quite a lot of others.

And, as mentioned, it's not what's under discussion here. It (like the others) uses pseudo-terminal devices, with the line discipline code in the kernel.

That's a graphical console, not a serial console.

Reply on news.ycombinator.com