Moving the Linux Kernel Console To User-Space

jones_supa sends this quote from Phoronix: "David Herrmann has provided an update on his ambitious initiative to kill off 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."

why?

[andjeng]

if something have any purpose, why should we kill it?

Unneeded

[Anonymous Coward]

Lets not mess with the TTY's they are STILL NEEDED for when things go wrong...

good thinking HA!

[rubycodez]

making console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possibile

But pleeeease keep the key-combo

[Anonymous Coward]

Being able to press ctrl-alt-f1 when anyting hangs the X server is why I feel more at home in linux than in windows or OSX.

Rule no 1

[Anonymous Coward]

If it works, don't fix it

It Works. Fuck It Up!

[Anonymous Coward]

So, it's relatively unchanged for "two decades". No one is complaining about it. It doesn't really seem to require improvement as it does what it needs to.

Yea, let's completely gut the system, move it to user space, introduce a metric shit ton of unexpected and undesirable behavior because... Well, Gnome is changing.

Uh

[christurkel]

a hardware-accelerated console

Why?

Re:why?

[Anonymous Coward]

I guess my questions boils down to this: why can't someone who wants a more advanced terminal just open up an X session, and put a few xterms on it? Please leave the very robust kernel console for its failsafe properties.

Re:Unneeded

[Anonymous Coward]

100x This ^^^

Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

You must be stupid, stupid, stupid

[fnj]

The linux kernel console; a lightweight, lightning-fast TEXT console not depending on X or anything else. Who needs it, eh? Are you kidding me? This is an imbecilic idea. If you must have pointless cruft like this, add it IN ADDITION to what has ALWAYS worked perfectly, is super reliable, and super simple. Hopefully set it up so that any mature user can leave this garbage out of his system.

This is just a continuation of the systemd, Gnome 3 type of insanity.

The way things are going, BSD, here I come. An OS by adults, for adults, not a would-be Windows me-too with stupid people gradually one-by-one breaking everything that has made linux great - up until now.

Re:why?

[jedidiah]

Quite. This sounds like a solution in search of a problem and users that actually care. On the other hand, it could break things horribly especially for those failsafe situations.

it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.

It seems like a perfect microsoftism.

What exact problem is this trying to solve?

[idontgno]

From TFA (to save your delicate eyes from the indignity of RTFA):

Among his principal complaints about the current terminal is that it's a user-interface in kernel-space, the code is poorly maintained, handles keyboards badly, produces bad font rendering, misses out on mode-setting and multi-head support, contains no multi-seat awareness, and only has limited hot-plugging handling, limited to VT102 compliance.

Let's look at this one item at a time.

1. "user-interface in kernel-space": Is this a philosophical objection? I'd argue that depending completely on userspace for system restoration is basically giving up on many classes of system problems. If you don't have user interaction at the kernel level, your only response to certain problems is reduced to "burn it down and rebuild it, lol". If you're all VM, sure, go nuts. But VM isn't universal, and restructuring Linux to only be usable in VM environments only is just foolish and shortsighted.
2. "code is poorly maintained": [Citation needed]. Is the complaint that it hasn't had commits in a while? Maybe because it's not broke? Simple capability with simple requirements probably attained stable maturity years ago. Maybe the committers should toss in a few random code restructures to make it look like someone cares.
3. "handles keyboards badly": Does it drop keystrokes? If it doesn't do that, there's absolutely no rational basis for this complaint. Maybe baby wants his arrow keys, or non-ASCII character set? Screw that. This is a console. Use vi commands like a grownup. And you don't need your umlauts and accents. The commands are all composed of ASCII characters. If you're reduced to using the console, internationalization is the least of your problems.
4. "produces bad font rendering": "bad font rendering?" "BAD FONT RENDERING?" Seriously? "It's not pretty enough?" I'm not even gonna address this drivel.
5. "misses out on mode-setting and multi-head support": Guess what. There is exactly ONE CONSOLE. It's for the use of ONE ADMINISTRATOR to restore function to a system which can't otherwise run in multi-head, multi-user modes. Not a problem.
6. "contains no multi-seat awareness": While you're at it, please complain that cars don't have multiple drivers' seats.
7. "limited hot-plugging handling": Interestingly, when system consoles were serial terminals like God intended, hot-plugging was a non-problem, since EIA RS-232 specifications meant that you could hot-plug serial cabling to your heart's content. Maybe thats' where the solution to this "problem" properly lies?
8. "limited to VT102 compliance": Oh, I'm so sorry it doesn't include your favorite terminal emulation. But it's good enough to run vi (properly statically linked, in /sbin), and that's as close to a GUI you'll ever get in system recovery operations. so, um, NO.

Re:why?

[Hatta]

The idea is to replace a kernel functionality with few features and several crucial limitations

But those few features are crucial.

The need for this arose primarily with the introduction of kernel mode setting etc.

And what happens when KMS fails? What happens when all you have are VGA text modes?

Will the user space console work in every instance where the current console works? If so, great. If we give up any of the reliability we've grown to rely upon, no thanks. I'd rather have a "lame console" I know will be there, than a full featured console I have to troubleshoot.

Re:why?

[Anonymous Coward]

So you two & everyone who's modded these up, thinks that 1) something being moved to a secondary option is the same as "being killed", and 2) that technology shouldn't be used to improve anything.

Please rethink.

Re:why?

[Anonymous Coward]

Wrong. Less functionality running in the kernel, the better. The kernel is a highly constrained environment, and it is also very security sensitive. Console processing does not belong there.

This sounds like yet another example of uninformed people assuming that they know anything about the subject matter at hand, and assuming that actual kernel developers do not.

Re:Going that way for a while now

[AwesomeMcgee]

I have already accepted that the linux I grew up on in the late nineties was killed (sometime in the mid-thousands I think, I was too busy working in .NET at the time to notice until I moved back to linux ~2009) and replaced by a completely opaque box, where everyone chides you for even thinking of recompiling your kernel ever because it will break everything, just choose one of the pre-compiled ones made by your linux masters.

I remember a beautiful simple system where everyone recompiled their kernels, it was simple and expected; and the system's components were independent enough to roll with changes like this, where running console-only didn't make you out to be a weirdo and switching versions of X wouldn't break every piece of your system, rather it would just switch your X.

Recently the linux I have met is a nice windows replacement. It acts like windows, I use it like windows, and the whole thing breaks if I try to change anything under the hood like windows.

Perhaps it's time to go back to FreeBSD, where simplicity was always the purpose, I sure hope in my time away from it (10 years now) it hasn't been won over by the dark side like linux was...

Re:why?

[Spazmania]

But it's not fully fledged.... it doesn't provide two of the three features I need in a text console: kernel diagnostic messages prior to the start of user space and kernel diagnostic messages following a crash.

Re:Unneeded

[PReDiToR]

And in the situation where your kernel didn't boot up and you're scratching your head, where are those messages that will help you?
All the text before:
Give root password for maintenance:
is very useful to some people.

I'll admit that I do tend to compile out early printk and most error messages, hide the init confirmations as much as possible and generally like a tidy boot sequence.
I like to know that I can put them back in when needed though.

Re:why?

[tibit]

It's not a long stretch to imagine that you can start a userspace process long before all of the kernel drivers are initialized. It's basically a big waste of time that the kernel delays starting init to *after* all the drivers are initialized. It's a waste of time. The applications that depend on functionality of certain parts of the kernel should simply wait until those parts become available. That's all there's to it. Also, the drivers can be initialized in parallel. No reason for the network card driver initialization not to run in parallel with waiting for the scsi raid driver to come up. The console doesn't need any of that and can be started up as the first thing, even if it were a userspace driver. Kernel usually starts off an initrd image, that's where the console application would be. I think it'd be wonderful if the kernel went in this direction, not only for console but for all other drivers as well. The applications that need to wait for certain things can get notifications when drivers get ready.

Re:why?

[Hatta]

What's wrong with it being in the userspace? At least if it crashes, it doesn't bring the whole kernel down. The process is relaunched by the kernel, and off you go.

Suppose you never make it to user space?

Re:why?

[fa2k]

Wrong. Less functionality running in the kernel, the better. The kernel is a highly constrained environment, and it is also very security sensitive. Console processing does not belong there.

When everything breaks down, it isn't worth much to have a rock solid kernel if you can't interact with it through a console

Re:Going that way for a while now

[sjames]

There have been a lot of improvements in Linux, but there has also been a lot of dane brammage shoveled in. Most of it is in userspace, but sadly, not all.

Gnome finally exceeded the maximum height BS can be piled and people are switching in droves. I have to agree that the new startup methods are mostly crap. I see no reason to pile in that much poorly documented crap to save 5 seconds at boot time (especially when we're not supposed to need to boot all that often).

I believe GP is referring to the situation in Fedora (perhaps changed now). For a while, it would break fairly badly if you dared to go back even a single sub-minor number on your kernel.

I am definitely NOT fond of grub2's configuration system. They took a simple and sane config and turned it into a 20 headed hydra full of config files and scripts that write config files. It's a very complex solution to a very simple problem and it needs to die. I have similar feelings about the way /dev is handled now. I can live with devices appearing and disappearing, but wit's with the bazillion little cryptic files.

It really IS becoming more opaque like Windows.

I certainly agree about the modelines. Good riddance to them. DDP is a win!