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.
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!
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 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! :)
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?
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.
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.