Originally posted by coder543
View Post
Announcement
Collapse
No announcement yet.
The Linux Kernel Console Is Being Killed Off
Collapse
X
-
Originally posted by ciplogic View PostSo, 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?
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.
Comment
-
Originally posted by coder543 View PostMy 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.
Comment
-
Originally posted by Uqbar View PostWe do need a low level access for emergencies. The simpler, the better. The earlier, the more effective.
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!Last edited by Rexilion; 08 February 2013, 08:40 AM.
Comment
-
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?
Comment
-
Originally posted by Rexilion View PostThat'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!
Comment
-
Originally posted by Vim_User View PostPractical 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?
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 ...
Comment
-
Originally posted by Vim_User View PostPractical 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 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!
Originally posted by coder543 View PostI still don't have a serial port on my desktop, so your solution is not workable.
Originally posted by Uqbar View PostI 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 ...Last edited by Rexilion; 08 February 2013, 09:06 AM.
Comment
-
Originally posted by Vim_User View PostPractical 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?
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.
Comment
-
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.
Comment
Comment