Hacker News Reader

Comment by chillaxtian | Hacker News Reader

i'm confused as to why the article implies the kernel is serving the shell.

isn't the shell usually a program running in userspace? that interprets commands, and prints characters on the screen, etc, in userspace? i didn't think the kernel was involved at all, except to receive exec syscalls.

View on HN

You're conflating the shell and the terminal. The shell is a running process, the terminal (or tty) is essentially an input-output device connected to the kernel. If you want to see what I mean, open a terminal and run the `tty` utility. It will print the device file for your current terminal (Probably a `/dev/pts/` entry). If you write any data to that 'file', it will appear in your terminal, and if you read from that file you'll get completely unfiltered input from the terminal (Unfiltered as in you simply see the keys as they are pressed. If you backspace, you'll see a backspace character - no line editing).
The kernel acts as the gatekeeper between the input/output of the processes running on a tty, and the input/output of the tty device itself. In 'raw' mode, the kernel simply takes the input from the tty and sends it as input to the running process, and then takes the output from the running processes and sends it as output to the tty device. The kernel still isn't completely pointless in this instance though, as it does provide some other facilities.

But it doesn't have* to do that. In 'cooked' mode (The default mode), the kernel will allow line-editing. It does this by buffering the inputs from the tty device (And writing them back to the tty device, so they appear on the screen) without actually sending them to the running processes until you press return.

The result is the programs like `cat`[1] which do nothing more then call `read()`, and send the buffer to `write()` still allow line editing features like backspace - even though the program itself has no concept of line editing (or even lines at all).

It should be clarified that modern `bash` does operate in raw mode, and handles all the line editing itself (The `readline` library also does this - I can't say for certain if `bash` uses `readline` internally or not, I haven't checked). Unix utilities like `cat` though don't change tty settings and thus are generally operating in `cooked` mode (You can change these settings via `stty`, but it's generally not necessary).

[1] https://github.com/DSMan195276/protura/blob/master/disk/util...

But try remapping C-w in bash. The tty remaps it on the very next line. You'll have to stty werase unmap it to be able to change it in your read line .inputrc.

So the tty cooking still has charge of some things.

I think that's actually just bash messing with you. Bash implements it's own erase-word and binds it to whatever is set to werase in the terminal, so if you don't clear the werase entry bash will just keep rebinding it every new prompt. It's definitely not the kernel's doing - for example vim, which also uses raw mode, can use C-w just fine, and the functionality bash gives to C-w is different from what the kernel provides.

The shell needs to print a prompt and read input. This is I/O, which involves the kernel. The shell is (when running interactively) attached to some terminal. These days it's usually a pseudo-terminal with a terminal emulator like xterm on the other end. (With some exceptions) the read syscall on a terminal does not return until there's a newline. The kernel only implements simple line editing. You can kill the whole like (^U) or erase the last character (^H i.e. backspace). Traditionally kill and erase were @ and # which you may see in some old documentation. On a hardcopy terminal you could type daat##te and it would run date. If the right flags are set, instead of outputting the erase character, Unix will back up, print a space, and back up again as described.

However the shell supports more line editing. I bet you can press the left arrow and edit the middle of the line. I bet you can press the up arrow and get the last line typed. I bet you can press ^A and get to the beginning of the line. The kernel doesn't do any of this, and you can't do it in cat. What happens is the shell turns off line editing. Then it gets all input unprocessed, and can decide what to do on it's own. This is why Chris Siebenmann put the PS in there.

It's true that modern shells like "bash" are receiving a stream of bytes in what is called the "raw" mode of the tty subsystem. For programs that don't switch to raw mode, though, the tty is generally in the "cooked" mode that has existed for most of the life of UNIX and similar platforms.

In cooked mode, the kernel is interpreting your input and provides basic line editing facilities -- only once you "commit" a line, generally by pressing something like carriage return or enter, does the kernel make the entire line available on the tty file descriptor.

That's why the author mentions "cat" as a way to witness the kernel's line editing behaviour: it generally leaves the terminal in "cooked" mode.

For historical reasons, there is way too much kernel level character input character processing in UNIX/Linux serial port code. That stuff belongs in user space today.

Yes. Though I guess it'll be with us forever more, just like the old complicated x86 instructions that nobody ever uses any more, but that no one is in a hurry to remove, because they only take up a very small fraction of the chip.

Seems like a huge difference between "instructions we don't use at all" and "ring 0 input processing we use constantly and can't stop using"

The only similarity seems to be "modern computers with legacy logic" which isn't terribly insightful.

You can also choose to ignore the reason-by-analogue I gave, and just take my prediction as a bet. I offer even odds at a 100 bucks that this ttl stuff will still be in the Linux kernel in 20 years.

I didn't ignore your reasoning, I acknowledged it and said it was not insightful.

Unused CPU instructions are difficult (but not impossible!) to deprecate for completely different reasons than the critical functionality of line discipline that is used all day every day and for which nobody has proposed a viable alternative.

Oh, the line discipline is fine. But why does this have to be kernel code?

Reply on news.ycombinator.com