4 ms·

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

by marvy 11y ago

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?

yuhong 11y ago
Hurd has a console server.
- JdeBP 11y ago
  The line discipline analogue isn't in the console daemon. It's in the term daemon. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/hurd-daemons.html#console http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/hu...
  - vive-la-liberte 11y ago
    You are the first person I've seen to ever include the rightmost dot in the domain name in a comment on the internet!
JoshTriplett 11y ago
> 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.
- marvy 11y ago
  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.)
  - JoshTriplett 11y ago
    Not every program that reads from stdin, just every program that wants stdin from a "cooked" TTY. Many programs can just perform raw reads.
Animats 11y ago
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.
- CountSessine 11y ago
  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. 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.
  - Animats 11y ago
    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.)
tatterdemalion 11y ago
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. :-)
JdeBP 11y ago
> 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.
EdiX 11y ago
> 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.

by marvy 11y ago

yuhong 11y ago

Hurd has a console server.

JdeBP 11y ago
The line discipline analogue isn't in the console daemon. It's in the term daemon. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/hurd-daemons.html#console http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/hu...
- vive-la-liberte 11y ago
  You are the first person I've seen to ever include the rightmost dot in the domain name in a comment on the internet!

JoshTriplett 11y ago

> 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.

marvy 11y ago
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.)
- JoshTriplett 11y ago
  Not every program that reads from stdin, just every program that wants stdin from a "cooked" TTY. Many programs can just perform raw reads.

Animats 11y ago

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.

CountSessine 11y ago
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. 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.
- Animats 11y ago
  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.)

tatterdemalion 11y ago

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. :-)

JdeBP 11y ago

> 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.

EdiX 11y ago

> 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.