The Linux Kernel Console Is Being Killed Off

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

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

[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?

[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!

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

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

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

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

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

[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?