The Linux Kernel Console Is Being Killed Off

[Rexilion]

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.

I'm all ears. Please teach me... . Said hypothetical situations were to demonstrate my point (of view, of course).

[Uqbar]

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?

I think about all those cases when the system is not fully booted. I use to get a few cases a year (on a dozen of test servers). I go to the server room, I switch the console and see. I usually do something like manually running fsck or ask for a temporary root shell.
There's no networking, no X windows, no DBUS, not even a login prompt but the plain-old 80x25 black and white local kernel console.
For a few machines I have a serial console con COM1 passed by the BIOS to GRUB to Linux kernel booting.
How would you do that with a DBUS console? You wouldn't be able to!
And I still think that using non-7BIT-ASCII in system administration is a mistake.

[Uqbar]

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.

Yeah! System administration is not the same as normal user activities. And when the going gets tough, the tough gets going. We need the plain old kernel consoles. Being that on local console (aka VGA/DVI/HDMI) or serial or whatever else it's irrelevant. We do need a low level access for emergencies. The simpler, the better. The earlier, the more effective.

[Rexilion]

We do need a low level access for emergencies. The simpler, the better. The earlier, the more effective.

That's what serial console's are for and designed to do.

Btw, as I argued before, current VT is big mess... . More ways to fail, so there goes your simplicity.

Two people saying the same does not make your point more valid. Just harder to argue with.

I'm starting to think there is an emotional aspect here. You do not seem to be sensitive to rational and practical arguments.

Furthermore, post #12 and #13 demonstrate, again, the misunderstanding of the difference between TTY and VT. You are not using VT at all if you use a serial console! DAMNIT!

[Vim_User]

Practical question, since I am still not getting it. When on a normal desktop PC (no serial console), with the new implementation, the system fails to boot, for example due to a corrupted/missing initrd, would I see the error messages on my physical display so that I can troubleshot the system?

[coder543]

That's what serial console's are for and designed to do.

Btw, as I argued before, current VT is big mess... . More ways to fail, so there goes your simplicity.

Two people saying the same does not make your point more valid. Just harder to argue with.

I'm starting to think there is an emotional aspect here. You do not seem to be sensitive to rational and practical arguments.

Furthermore, post #12 and #13 demonstrate, again, the misunderstanding of the difference between TTY and VT. You are not using VT at all if you use a serial console! DAMNIT!

I still don't have a serial port on my desktop, so your solution is not workable.

[Uqbar]

Practical question, since I am still not getting it. When on a normal desktop PC (no serial console), with the new implementation, the system fails to boot, for example due to a corrupted/missing initrd, would I see the error messages on my physical display so that I can troubleshot the system?

I would say so. That's what happens.
The other option is to boot with another bootable medium and try to see what happened... but the boot errors will be gone, then. As there's no booted system,there will be no logs ...

[Rexilion]

Practical question, since I am still not getting it. When on a normal desktop PC (no serial console), with the new implementation, the system fails to boot, for example due to a corrupted/missing initrd, would I see the error messages on my physical display so that I can troubleshot the system?

If initrd is missing grub will scream about it. If initrd is there GRUB will allow it.

I think (not sure) that in some cases GRUB will also scream on a corrupted initrd. But the fact that this is in some cases, will of course, not help you.

As mentioned in the article, the author of KMSCON is also working on a VESA DRM and UEFI DRM implementation. These should be build into the kernel. So once the kernel starts loading initrd, it's already done with TTY and and setting up VESA or UEFI DRM. Those could, in theory, give you an error.

One might say: You are replacing the VT output with something from DRM. Yes that is right, it's called FBLOG from the exact same author. But it's much more simpler and exactly tailored for the purpose. This is all done to lower maintenance cost.

Don't worry, they got your back!

I still don't have a serial port on my desktop, so your solution is not workable.

Then you don't need the early (pre x86 printk) output the VT is providing you as well. (I'm referring to CONFIG_EARLY_PRINTK).

I would say so. That's what happens.
The other option is to boot with another bootable medium and try to see what happened... but the boot errors will be gone, then. As there's no booted system,there will be no logs ...

Covered. If I'm not mistaken, you can thank the Android folks for that. Ow and that is the mechnism used right now for debugging phones. So, where is VT needed?

[Lynxeye]

Practical question, since I am still not getting it. When on a normal desktop PC (no serial console), with the new implementation, the system fails to boot, for example due to a corrupted/missing initrd, would I see the error messages on my physical display so that I can troubleshot the system?

Yes you will still get that, but not through the fbcon layer. The thinking was more of stealing the framebuffer of whatever was active at the time and display the OOPS. Please differentiate between normal console operation and a fault situation where you want to get some debug spew.

No one will take away the ability to get debug information on the screen, but most people would also like to have a capable console without all the races, deadlocking and a sane API, which is exactly why the normal console belongs into userspace.

[Rexilion]

A more general remark: This follows the rule of 'doing one thing, and doing one thing good'.

Why have 1 system, the VT subsystem, handle virtual console's and debugging which caused it to became a huge unmaintainable mess while you can have 2 different systems that handle both tasks in a much better and maintainable way. Like this:

- DRM + FBLOG + DRM(VESA + UEFI) = Debugging
- KMSCON = virtual console

Tell me what is wrong about that.

Ow and, before we get into this: FBLOG is not like any other FB driver. It's designed to show only output and to replace fbcon. This is exactly the mechanism that is described in post #19.