The Linux Kernel Console Is Being Killed Off

[phoronix]

Phoronix: The Linux Kernel Console Is Being Killed Off

David Herrmann has provided an update on his ambitious initiative to kill of the Linux kernel console. Herrmann has long been working on making the Linux kernel CONFIG_VT option unnecessary for providing a Linux console by punting it off to user-space. The Linux kernel VT console hasn't been changed much in the past two decades and Herrmann is hoping to see it replaced with a user-space solution he's been developing that would allow for multi-seat support, a hardware-accelerated console, full internalization, and other features...

http://www.phoronix.com/vr.php?view=MTI5Njc

[Uqbar]

And I admit I could be badly wrong.
So I need some hints to lower my stupidity.

Zeroth question: what's a kernel console for?
It serves mainly to two purposes. To provide some booting diagnostics, especially in the earliest phases, before even the INIT has been run. Second, to provide a way to interact with the system when it has not completely booted yet. I'm sure there's more here.

First question: why should we kill the kernel console? To save memory? To make the boot faster? To gain extra features? I'd like to see how these would benefit the kernel and the system administrators.

Second question: Multi-seat hardware-accelerated fully-internationalized kernel console? What would it be the plus? The real one, I mean. To enter shell commands in Chinese, Arabic or with proper diacritics? To get super-fast 3D console rendering at (AFTER) the kernel boot? All those "plura" are not less then bullshit in my mind.

Third question: what if I have to troubleshoot a system which has not fully booted yet? I mean things like forced fsck, issues with the /etc directory contents and so on. No userland, no console!

Fourth question: You say that code is poorly maintained, right? So why don't you just ... maintain it?

Fifth question: Maybe all this is for mobile smartphones running Linux, right? Please, I need some more details here as I don't get the point.

Thanks in advance.

[Rexilion]

I'm not an expert on this, but...

Zeroth question: what's a kernel console for?
It serves mainly to two purposes. To provide some booting diagnostics, especially in the earliest phases, before even the INIT has been run. Second, to provide a way to interact with the system when it has not completely booted yet. I'm sure there's more here.

Serial console?

First question: why should we kill the kernel console? To save memory? To make the boot faster? To gain extra features? I'd like to see how these would benefit the kernel and the system administrators.

That is somewhat arbitrary. Why not put the entire libusb in the kernel? It will save memory as well and will make USB devices connect faster. From what I understand it, it's pretty hard to write good kernel code. So why not make sure that what is in the kernel is small, yet able to provide everything you need in userspace.

Second question: Multi-seat hardware-accelerated fully-internationalized kernel console? What would it be the plus? The real one, I mean. To enter shell commands in Chinese, Arabic or with proper diacritics? To get super-fast 3D console rendering at (AFTER) the kernel boot? All those "plura" are not less then bullshit in my mind.

I guess this could be done in the kernel as well. But would really bloat it.

Third question: what if I have to troubleshoot a system which has not fully booted yet? I mean things like forced fsck, issues with the /etc directory contents and so on. No userland, no console!

First question: serial console. Furthermore, who said you need rw access to root in order to use it's library's and code? Where do you think fsck is coming from? The kernel? Yes, it could be placed in initramfs so why not kmscon?

Fourth question: You say that code is poorly maintained, right? So why don't you just ... maintain it?

I guess it's ugly because it's not supposed to be there anymore. Furthermore, from what I read on LKML, it's a mess with respect to code readability. So maintaining is quite an efford. Furthermore, making structural changes might break stuff due to it's subtle sematics (i.e. races).

So that would be an argument to start from scratch using today's standards (e.g. UTF-8, OpenGL) and Linux specific 'standards' (e.g. DRM)

Fifth question: Maybe all this is for mobile smartphones running Linux, right? Please, I need some more details here as I don't get the point.

Use a serial console for smartphone development. Furthermore, for Android, there are VM's available.

In the end, I guess you could say that using different parts of the kernel you can actually achieve the same result instead of having to everything specifically for VT's only. I.e. DRM for rendering and the kernel's process management for handling it's... processes. And instead of doing drawing operations in the kernel, why not use a library specifically designed for this?

[ciplogic]

And I admit I could be badly wrong.
So I need some hints to lower my stupidity.

Zeroth question: what's a kernel console for?
It serves mainly to two purposes. To provide some booting diagnostics, especially in the earliest phases, before even the INIT has been run. Second, to provide a way to interact with the system when it has not completely booted yet. I'm sure there's more here.

First question: why should we kill the kernel console? To save memory? To make the boot faster? To gain extra features? I'd like to see how these would benefit the kernel and the system administrators.

I think are many answers. First of all I think can be based on this presentation: http://mirror.linux.org.au/linux.con...pace_sucks.mp4

Kernel code is harder to develop, extend, interoperate with user tools, so here I think the problem lies on.

Second question: Multi-seat hardware-accelerated fully-internationalized kernel console? What would it be the plus? The real one, I mean. To enter shell commands in Chinese, Arabic or with proper diacritics? To get super-fast 3D console rendering at (AFTER) the kernel boot? All those "plura" are not less then bullshit in my mind.

Diacritics are crucial for renames for example. You may not use it as you are an English speaking writer. Word saves by default the document based on the first line you write, so your document can have a lot of nasty characters which are hard to be renamed using your keyboard. My wife uses Russian letters are I always move/rename them inside Nautilus because is impractical to add anything from console.

Accelerated console? You misunderstood in part what is it about: many services are much easier to access from coding standpoint from user-space including services for accessibility, internationalization or a decent 3D library (openGL), which a terminal service can benefit from. In kenel space you don't have these capabilities, not because the drivers are not loaded somewhere in kernel space, but because are exposed in a hideous way inside kernel to make any interesting implementation aspects.

Third question: what if I have to troubleshoot a system which has not fully booted yet? I mean things like forced fsck, issues with the /etc directory contents and so on. No userland, no console!

The troubleshooting can be done by exploring for example /proc and /dev (but there will be no TTY). SystemD has its diagnostics and can be written an user-space module that will output the failures much later after the kernel boots.

Fourth question: You say that code is poorly maintained, right? So why don't you just ... maintain it?

Because coding inside kernel is harder than in user-space. Also, if a crash, if memory leaks occurs in the terminal service, you can simply kill the service and leaks are gone.

Fifth question: Maybe all this is for mobile smartphones running Linux, right? Please, I need some more details here as I don't get the point.

Thanks in advance.

Fifth point I think is also a misunderstanding from your source, but removing a service that by default is not used by constraint devices (SystemD will do the job just fine) is good for phones, as they will save some KB of kernel space (yay!) which is fairly important for constrained devices.

[Vim_User]

I have troubles to understand this and therefore needs some questions answered:
If the console is in user-space, how can we debug situations on desktop PCs (without the possibility to connect a serial console) where the kernel can't find the initrd or the root-partition, means: no userspace available?
How can systemd help if you either have a system without it or it gets not loaded because of the problems mentioned in the first question?

[Uqbar]

I'm not an expert on this, but...
Serial console?

Correct, but then you need extra hardware (a PC and/or a console server and/or a serial adapter) in order to troubleshoot a boot process! Serial consoles are quite useful, indeed. Still I don't see the point about killing the kernel console which, I think, shares code with the "other consoles".
If your platform doesn't have a "local terminal" (aka graphics adapter w/ VGA-DVI-HDMI output), then the serial console is the only one option. And it is in kernel space!

That is somewhat arbitrary. Why not put the entire libusb in the kernel? It will save memory as well and will make USB devices connect faster. From what I understand it, it's pretty hard to write good kernel code. So why not make sure that what is in the kernel is small, yet able to provide everything you need in userspace.

Sorry, I don't understand this. Are you talking about "USB kernel consoles"? I don't mind about console speed. I mind about it being available as soon as possible. And, going back to previous point, you need serial drivers anyway into the kernel in order to have that.

I guess this could be done in the kernel as well. But would really bloat it.

Infact I'm arguing that those extra features would be completely useless both as kernel built-in and in userland. I don't see the point in doing that at all, especially the USB thing.

First question: serial console. Furthermore, who said you need rw access to root in order to use it's library's and code? Where do you think fsck is coming from? The kernel? Yes, it could be placed in initramfs so why not kmscon?

Same as above. I need extra hardware for troubleshoot or just to check the booting process. And moreover I'm not willing to kill the serial console either!

I guess it's ugly because it's not supposed to be there anymore. Furthermore, from what I read on LKML, it's a mess with respect to code readability. So maintaining is quite an efford. Furthermore, making structural changes might break stuff due to it's subtle sematics (i.e. races).
So that would be an argument to start from scratch using today's standards (e.g. UTF-8, OpenGL) and Linux specific 'standards' (e.g. DRM)

I wish I could get more than guesses. Anything requires effeorts and resources. Do you think a kernel console is useless? Then fight for a complete removal. Otherwise make it as useful as possible.
UTF-8 in the kernel console? I think I missed something. I thought that all internal kernel human messaging was in English with 7BIT-ASCII. My bad!

Use a serial console for smartphone development. Furthermore, for Android, there are VM's available.

Smartphones do not use X (maybe Wayland in the future) but the frame buffer. I didn't get any possible reasons for getting a userland console in Linux based smartphones, a very peculiar Linux platform...

In the end, I guess you could say that using different parts of the kernel you can actually achieve the same result instead of having to everything specifically for VT's only. I.e. DRM for rendering and the kernel's process management for handling it's... processes. And instead of doing drawing operations in the kernel, why not use a library specifically designed for this?

Stop guessing. I'll try to explain myself better.
I'm just saying that I don't see reasons to move the kernel console out of ... the kernel.
I say that we do need a kernel console, maybe we need a better kernel console, but that would hardly require hardware acceleration, internationalization and multiple seats.
I say that a kernel console needs to be available as soon as possible at boot. Full stop. Anything else sounds useless to my poor mind.
Once I get the boot done I can use normal pseudo terminals with TELNET/SSH/whatever and even X terminals on both local and network displays. That'd be it.

[Uqbar]

Diacritics are crucial for renames for example. You may not use it as you are an English speaking writer. Word saves by default the document based on the first line you write, so your document can have a lot of nasty characters which are hard to be renamed using your keyboard. My wife uses Russian letters are I always move/rename them inside Nautilus because is impractical to add anything from console.

If you use non-7BIT-ASCII for your system configuration files, then you are right.
I run a number of Linux servers. I have UTF-8 for both contents and file names. But only for user related suff.
For the operating system I still stick with plain-old-7BIT-ASCII. I don't create usernames with diacritics in /etc/passwd and /etc/shadow.
I don't edit system files with Word or LibreOffice. I use vim (or emacs or whatever text editor is available).
I don't rename or link the "who" command as "chi_è" (that's Italian for "who is that").
I don't set the $PATH variable with directories whose name contain non 7BIT-ASCII names.
Maybe this is why I don't see that usefulness and hardly understand your other remarks ... sorry.
I talk about the kernel console, not the user terminal or windows.

[ciplogic]

If you use non-7BIT-ASCII for your system configuration files, then you are right.
I run a number of Linux servers. I have UTF-8 for both contents and file names. But only for user related suff.
For the operating system I still stick with plain-old-7BIT-ASCII. I don't create usernames with diacritics in /etc/passwd and /etc/shadow.
I don't edit system files with Word or LibreOffice. I use vim (or emacs or whatever text editor is available).
I don't rename or link the "who" command as "chi_è" (that's Italian for "who is that").
I don't set the $PATH variable with directories whose name contain non 7BIT-ASCII names.
Maybe this is why I don't see that usefulness and hardly understand your other remarks ... sorry.
I talk about the kernel console, not the user terminal or windows.

So, let's take this case in more detail: you are a highly skilled admin, and I think that the issue details are what are missing in discussion.

There is no problem in console mode if you get the relevant logs if the console is started as part of kernel as /dev/tty1 - 6 or if you get it as an user-space application that doesn't have any /dev/tty mapping. Or the mapping of UTF8 or UTF7.

Why you care if is /dev/ttyX or is not mapped on a TTY terminal? Even more, why would you mind if can give for less advanced users more user-space capabilities?

Removing it from kernel, can give for consoles access to DBus framework (so terminal can be called via GObject or Qt's DBUS).

At the end, /dev/ttyX is not exactly what is the concern, right? Is the idea to have a way of logging the kernel, and this can be done on screen in the "kernel panic" screen, with no need of full terminal implemented there, right?

[Rexilion]

Correct, but then you need extra hardware (a PC and/or a console server and/or a serial adapter) in order to troubleshoot a boot process!

That is kind of arbitrary. Right now, you could also face problems where the current VT system is not ready to do anything. Printing nothing before the screen is ready and you need a serial for that. Think of people porting new architectures to the linux kernel, one by one. You start with serial printing as that is the most basic output device.

So, some problems that you were able to see with a kernel VT are not observable anymore with KMSCON. This is kind of arbitrary, so why not make a new design that lowers maintainence cost? Furthermore, if my kernel were to regress that it would not boot on my amd64 machine into a state where output is not ready. I could do a bisect, no (direct) need for a serial.

Serial consoles are quite useful, indeed. Still I don't see the point about killing the kernel console which, I think, shares code with the "other consoles".
If your platform doesn't have a "local terminal" (aka graphics adapter w/ VGA-DVI-HDMI output), then the serial console is the only one option. And it is in kernel space!

Ah, the good old confusion between a TTY and VT.

A physical hardware serial console is the same as a VT. Only the VT is virtual.

Sorry, I don't understand this. Are you talking about "USB kernel consoles"? I don't mind about console speed. I mind about it being available as soon as possible. And, going back to previous point, you need serial drivers anyway into the kernel in order to have that.

It was to make my point more obvious. You mentioned performance related metrics into the decision whether to do something in the kernel or in userspace. You could make your system lightning fast if everything were to be in kernelspace. But if your browser crashed your probably have to reboot your computer. Ow, and don't think you can have nice thinks like DAC anymore.

Infact I'm arguing that those extra features would be completely useless both as kernel built-in and in userland. I don't see the point in doing that at all, especially the USB thing.

It was to make my point. My response to this was that it would bloat the kernel with functions that are perfectly done in userspace. Again, I repeat: The difference between what to do in the kernel and in userspace is somewhat arbitrary. However, giving the trend you see with the video subsystem this move would be 'in par' with that trend. I never said it was 'good'. I would probably suck less given today's spaghetti code in kernel VT.

Same as above. I need extra hardware for troubleshoot or just to check the booting process. And moreover I'm not willing to kill the serial console either!

[sarcasm]First response. I never knew you did architecture development? What are you working on? [/sarcasm off]

I wish I could get more than guesses.

I never state opinion as fact. I just point my opinion. Hence, this is a discussion board. If we were to talk about facts only, this thing would not exist.

Anything requires effeorts and resources. Do you think a kernel console is useless? Then fight for a complete removal. Otherwise make it as useful as possible.

A different approach to solve the same problem could yield lower maintainence cost.

UTF-8 in the kernel console? I think I missed something. I thought that all internal kernel human messaging was in English with 7BIT-ASCII. My bad!

ronald@Alpha ~ $ cat /usr/src/config | grep UTF
CONFIG_NLS_UTF8=y

Smartphones do not use X (maybe Wayland in the future) but the frame buffer. I didn't get any possible reasons for getting a userland console in Linux based smartphones, a very peculiar Linux platform...

Again, the difference between VT and TTY as pointed out as above. According to your reasoning, Wayland should be in the kernel as well. And that would imply X would be in it right now!

Stop guessing. I'll try to explain myself better.
I'm just saying that I don't see reasons to move the kernel console out of ... the kernel.
I say that we do need a kernel console, maybe we need a better kernel console, but that would hardly require hardware acceleration, internationalization and multiple seats.
I say that a kernel console needs to be available as soon as possible at boot. Full stop. Anything else sounds useless to my poor mind.
Once I get the boot done I can use normal pseudo terminals with TELNET/SSH/whatever and even X terminals on both local and network displays. That'd be it.

Again: Difference between TTY and VT. VT is a way of displaying TTY input/output. Why VT in the kernel, and not Wayland? Wayland could display Oops messages as well.

[coder543]

That is kind of arbitrary. Right now, you could also face problems where the current VT system is not ready to do anything. Printing nothing before the screen is ready and you need a serial for that. Think of people porting new architectures to the linux kernel, one by one. You start with serial printing as that is the most basic output device.

So, some problems that you were able to see with a kernel VT are not observable anymore with KMSCON. This is kind of arbitrary, so why not make a new design that lowers maintainence cost? Furthermore, if my kernel were to regress that it would not boot on my amd64 machine into a state where output is not ready. I could do a bisect, no (direct) need for a serial.



Ah, the good old confusion between a TTY and VT.

A physical hardware serial console is the same as a VT. Only the VT is virtual.



It was to make my point more obvious. You mentioned performance related metrics into the decision whether to do something in the kernel or in userspace. You could make your system lightning fast if everything were to be in kernelspace. But if your browser crashed your probably have to reboot your computer. Ow, and don't think you can have nice thinks like DAC anymore.



It was to make my point. My response to this was that it would bloat the kernel with functions that are perfectly done in userspace. Again, I repeat: The difference between what to do in the kernel and in userspace is somewhat arbitrary. However, giving the trend you see with the video subsystem this move would be 'in par' with that trend. I never said it was 'good'. I would probably suck less given today's spaghetti code in kernel VT.



[sarcasm]First response. I never knew you did architecture development? What are you working on? [/sarcasm off]



I never state opinion as fact. I just point my opinion. Hence, this is a discussion board. If we were to talk about facts only, this thing would not exist.



A different approach to solve the same problem could yield lower maintainence cost.







Again, the difference between VT and TTY as pointed out as above. According to your reasoning, Wayland should be in the kernel as well. And that would imply X would be in it right now!



Again: Difference between TTY and VT. VT is a way of displaying TTY input/output. Why VT in the kernel, and not Wayland? Wayland could display Oops messages as well.

I'm just going to jump in here and point out that you have no clue what he is talking about. I don't have time this morning to completely destroy each and every one of your 'points', but I will alert you to the fact that he was never suggesting X is in the kernel or should be moved there. He was saying this userland terminal system would be dependent on X or Wayland on the desktop, and that smartphones right now use neither. For people debugging said devices, this would only cause more trouble, especially if the serial console was done away with as well.

My side of this argument is that the whole idea is crap. The VTs are only ever used as a last resort, so the simpler they are, the more likely they are to be functional. I don't want them replaced by a feature filled (bloated) userland terminal. Recovery of the system should never require internationalized letters. If you want to manage a Cyrillic filesystem through a terminal, then either fire one up after the boot, in userland, or add support for internationalization alone to the VTs, but simpler is better. This whole idea reeks of unnecessary complication.

Edit: the VTs are also used for server management and by Arch gurus. So, sure, go ahead and make a better VT, but it had better be an extension you can manually load from a normal VT.