Moving the Linux Kernel Console To User-Space 311
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? (Score:2, Insightful)
Re: (Score:2)
Re: offcourse (Score:3)
Re:why? (Score:5, Insightful)
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: (Score:3)
It is the terminal emulator part of the console which is going to user space (optionally). The console itself will not go away, so your serial port console is safe.
The built-in terminal emulator is pretty good for a 90's piece of software, but it is showing its age and the limitations are difficult to fix in kernel space.
Re: (Score:3)
Re:why? (Score:5, Informative)
The idea is to replace a kernel functionality with few features and several crucial limitations with a user space solution that is fully-fledged. The fully-fledged solution is not what you want to have inside the kernel, therefore taking the console to user space.
The need for this arose primarily with the introduction of kernel mode setting etc. Before these advances, the console would somewhat be lame by definition. Now it is much more viable to have a nice console even without a windowing system and that opens new applications to a user-space console.
E.g. look at Terminology. It is a virtual terminal emulator from the Enlightenment guys, built on the EFL core libraries. It works with David Herrmanns patches, without X11 or any display server!
http://www.youtube.com/watch?v=AD-BJThtNnc (here run within X)
Compare this to the basic kernel console. It could replace it if David's work gets through.
Re:why? (Score:4, Insightful)
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: (Score:3, Insightful)
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.
Re:why? (Score:4, Insightful)
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: (Score:3)
Re:why? (Score:4, Insightful)
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:why? (Score:4, Insightful)
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? (Score:4, Interesting)
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. It's the Erlang mantra of reliable software: fail fast, in limited scope. I love it. That's why I'm a big fan of userspace drivers for all devices that are application-specific. Suppose you have a USB-based toy that has a vendor-specific functionality and isn't one of the standard USB device classes. You have an application for. It should only have a userspace driver bundled with the application. You start the app, it claims any USB devices it can handle, and goes from there. That's often how it's done on OS X, it's quite onpopular on Windows, unfortunately.
Re:why? (Score:5, Insightful)
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: (Score:3)
I've never seen the character based console crash in linux.. not once in 15+ years. The uvesafb graphic mode consoles for non-x86 and x86_64 are another story, and because they don't initialize until halfway through the kernel's boot, the earliest printk() text is lost. DRM2 hardware accelerated drivers like nouveau seem to catch it all, but I"ll bet users have had more crashes with this than with the VGA character mode console. There's just more code being shoved around and more hardware being monkeyed w
Re:why? (Score:5, Insightful)
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? (Score:5, Insightful)
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.
Unneeded (Score:5, Insightful)
Lets not mess with the TTY's they are STILL NEEDED for when things go wrong...
Re:Unneeded (Score:4, Insightful)
100x This ^^^
Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.
Re: (Score:2, Insightful)
I remember a beautiful simple system where everyone recompiled their kernels,
Re: (Score:2)
Re: (Score:2)
FreeBSD should still be good for you. If not, go play with OpenBSD.
Re: (Score:3)
I used Linux in the late 90s and I really don't miss my younger siblings crashing my Linux machine by switching back and forth from X to console too quickly. I also don't miss having to enter modelines to get my screen working or write my dialup scripts from scratch.
FYI I don't know what distro you are using but I still recompile since precompiled kernels don't come with things like RDP (I'm experimenting). It's even easier than it was in the 90s.
Re:Going that way for a while now (Score:4, Insightful)
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!
Re:Unneeded (Score:5, Insightful)
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: (Score:2)
Except that on a VM the need is not the same.
And on a phone also different.
Is it really useful to have an ANSI escape sequence interpreter in the kernel ?
Much of the legacy could be removed/replaced on those kernels.
Re: (Score:2)
Your VM host is broken.
Re: (Score:2)
The only use for a console when the kernel is so hosed it cannot run any user space is to see the kernel's panic message. The console NOW is not useful unless user space is working. The issues I see are just details on how the console functionality gets moved to user space. It needs to support BOTH framebuffer and text mode displays. But definitely, all those things like cooked line input and such should be in user space, and even pluggable with a clean well defined interface that can be used in C as we
Re: (Score:2)
Note that cooked line input is not part of the "console", it's part of the tty system.
Re: (Score:2)
Which is very useful for troublesolving.
Re: (Score:2)
Re: (Score:2)
Does your company do any kind of development with hardware? If so, someone somewhere probably needs it for debugging, and so it's in the list for machines used by developers.
Re: (Score:3)
good thinking HA! (Score:5, Insightful)
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
Re:good thinking HA! (Score:5, Funny)
Re:good thinking HA! (Score:5, Funny)
I think it should require Unity and a touchscreen
Re:good thinking HA! (Score:5, Funny)
I await the new console with gesture support. There is one gesture I regularly make to systems that are so broken I have to use the console.
Re: (Score:3)
poettering should make it part of systemd! problem solved!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
Ain't broke. Nuff said. Okay..., maybe not quite, but let's solve the problem(s) without creating new ones. And yes, busting the console most definitely will create problems.
Re: (Score:3)
I suggest 2 different consoles, neither of which would need to be there for the kernel to do it's thing of running user space processes. One would be an optional in-the-kernel console complete with an in-the-kernel shell. Trim down it's capability and keep it small. The other would be an optional all-user-space console which can use the many user-space shells we already have, or any other program we want. PTY's definitely need to be pure user-space.
Re: (Score:2)
had funny thought, this might work in MINIX kernel architecture, but not monolithic one
Re: (Score:2)
Running the console in User Space really meaning running a kernel thread in the unprivileged mode of the CPU. If you do a process listing on a current system, most of the PID's < 100 are user space threads launched from within the kernel itself and part of the kernel code base. These include things like USB management, software RAID, swapd, ext4-dio-unwrit. They don't create external dependencies. The chief benefit is that failures in those threads can't take the whole system down. I'm surprised we
But pleeeease keep the key-combo (Score:5, Insightful)
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.
Re:But pleeeease keep the key-combo (Score:4, Informative)
When you are on the X console, all keys are handled by X, including the Ctrl-Alt-F1 (that's why if you lock up X badly, even Ctrl-Alt-F1 won't work, although you may still be able to remotely log in and fix things; assuming you have sshd or something equivalent running, of course). However switching back to X11 with Ctrl-Alt-F7 (or whereever your current X session is) is handled by the console.
Re:But pleeeease keep the key-combo (Score:5, Informative)
Re: (Score:2)
Yet this is the first thing you have to disable on a multi-seat system because it will bork your system otherwise.
It's useful in some scenarios, but it is, in essence, a hack which only works in some scenarios. A multi-seat-aware VT would be a blessing.
Rule no 1 (Score:2, Insightful)
If it works, don't fix it
Re: (Score:2, Funny)
Yeah, but the first rule of Linux is: If it ain't broke, take it apart and compile your own
Re:Rule no 1 (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Fix it' till it breaks.
Re: (Score:2)
Re: (Score:3)
It Works. Fuck It Up! (Score:4, Insightful)
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.
Re: (Score:2)
"It ain't broke so don't fix it." is a good rule to live by in a production environment. In development/in innovation you have to look at everything and think, "can it be better?"
Re: (Score:2)
The problem comes when the people in charge think something is better and it gets pushed on others even though they disagree about it being better. We have seen this happen sufficiently often with software (both open and closed source) recently that whenever something like this is announced we fear it happening again.
Re: (Score:3)
And that's fine, as long as you accept that at least sometimes, the answer is "No."
Re: (Score:3)
If we took this attitude for everything, then we would still be banging rocks, because they work fine.
At this point let the guys demonstrate their concept and see how well it works. A compromise could be simply to keep a minimal set of TTY devices for situations where userspace royally failed. It should be noted that for a good number of cases if userspace royally screwed up, then it is time for a reboot anyhow.
Re:It Works. Fuck It Up! (Score:4)
With that argument you kill off a lot of innovation. We don't need cars, we had horse buggies for centuries, right?
You didn't cut off your legs when you got a horse. You didn't shoot all the horses when you got a car.
The console is there to fix the system when someone fscks it up. Making it reliant on a ton of user-space code is a really bad idea.
Re: (Score:2)
Wrong Analogy (Score:3, Informative)
Good troll, but the better analogy would be car steering wheels haven't changed in decades. They're all round and don't come in many colors or properly support knee control. So, I want to move them into the back seat so they don't get in the way.
Re: (Score:2)
No! The Austin Allegro had a square steering wheel.
Re: (Score:3)
Amusingly, a century ago the complaint was that "tillers worked just fine for steering boats so why change things?" so the first cars were steered by tiller.
Re: (Score:2)
If I remember correctly, comparative studies have shown that a joystick is a better way to steer a car than a steering wheel. So they were probably right.
Re: (Score:3)
Why would a joystick need to be 1:1 with the mechanical system? Surely some form of damping would address the spurious input. And as for g-forces... fighter jets have joysticks!
I Can't Wait (Score:4, Funny)
I can;t wait to hear Linus' response to this plan. I expect it to be something like...
How 'bout noh! You crazy Dutch bastard. [youtube.com]
Uh (Score:5, Insightful)
Why?
Re: (Score:2)
Multitouch onscreen keyboard in Stereoscopic 3D, it's like, the future, man.
Re: (Score:2)
Re: (Score:3)
Because the KMS terminal is so slow that anything that outputs stdout or stderr to it will slow down by orders of magnitude.
Note -- the old-style VGA console was HW-accelerated. This is what you get if you use binary blob drivers. The new console, using kernel modesetting and native resolution, isn't. Try compiling something large with lots of console output on a KMS framebuffer. It absolutely hurts.
Re: (Score:2)
One thing I hate about the console is that it's slow.
If you have a driver or piece of HW that misbehaves so lots of kernel messages are printed, scrolling the console screen becomes a bottleneck and the system becomes unresponsive. I've had cases where it took over a half hour to shut down. End users will typically be less patient.
Re: (Score:2)
Look at the details, this is a joke (Score:3)
When I read "a hardware-accelerated console" I though that it must be a joke. This whole story. /. headlines...
Bravo! He made it on
(otherwise this kind of idea could have made me feel quite anxious)
Re:Look at the details, this is a joke (Score:5, Informative)
The VT console has been "hardware accelerated" under x86/VGA for years. You don't think it's actually copying memory line for line when it needs to scroll the screen, do you? No, it's incrementing the VGA register that tells it what memory address to start drawing text from.
Re: (Score:2)
At least on primitive VGA subsystems like the ones you see on servers because they're integrated with the BMC for IPMI, yes, it's clearly copying memory. They often scroll only around 20 to 50 lines per second.
Re: (Score:2)
P.S. in graphics mode - 80x25 text is fast of course.
Re: (Score:2)
Wellll, actually, it's doing that, but the BIOS software is emulating the legacy behavior you see.
Re: (Score:2)
Back in the days of CGA we had a hardware-accelerated console. We do have it to this day, as long as framebuffer is not involved. I've seen a server that takes around a whole booping second to switch VTs. Displaying a screenful of text wasn't pleasant, either.
Noob me? (Score:3)
Learned something new today - because, until now i was always assuming the console already did run in user space, and was as friendly to print kernel messages.
You must be stupid, stupid, stupid (Score:3, Insightful)
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: (Score:2, Interesting)
Re: (Score:2)
The linux kernel console; a lightweight, lightning-fast TEXT console not depending on X or anything else.
The linux console is slow as hell. This does not distinguish it from other consoles throughout history or in the present day, except that it actually makes it substantially faster than the average Sun console. And that idea is probably out of data, I know it was on Solaris-x86, where it was approximately as slow.
With that said, while I'd like to see a faster console, I don't require more functionality from it.
Re: (Score:2)
The linux kernel console; a lightweight, lightning-fast TEXT console not depending on X or anything else.
I guess that you don't use Linux drivers, but rely on third party blobs.
Ever since Linux switched to kernel-based modesetting, the console has switched to a framebuffer console. No accelerated VGA text mode, but pixel blitting.
It is painfully slow.
If you must have pointless cruft like this, add it IN ADDITION to what has ALWAYS worked perfectly, is super reliable, and super simple.
It is fundamentally broken in many scenarios, like multi-seat. I canot use Linux console, for example, because it is not multi-seat aware. It is not only not reliable, it will bork your system because it accepts all keyboard input.
Re: (Score:3)
You're flat-out wrong with calling the standard console "ultra-fast"
Wall-clock time to run "tree" on 152,724 files on my Arch system (repeated runs were made for each technique to ensure consistency):
1. Using the supposedly bloated & slow Konsole under KDE: 1.8 - 1.9 seconds.
2. Using the supposedly "ultra-fast" kernel konsole: 12.7 - 12.8 seconds.
If you aren't using a serial port (Score:4, Informative)
then you aren't really using a "failsafe" console. Even Windows has this with it's "Special Administration Console" / "Emergency Management Services."
When I was building custom kernels for my server I would remove the VT support. Pure serial.
So I don't care. Sounds good from a design standpoint. Should have the least in the kernel possible - simple = robust.
What exact problem is this trying to solve? (Score:5, Insightful)
From TFA (to save your delicate eyes from the indignity of RTFA):
Let's look at this one item at a time.
Re:What exact problem is this trying to solve? (Score:4, Informative)
"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.
Maybe the user wants to get the ">" symbol on pressing the ">" key. Which is different on different keyboard layouts. Doesn't seem too unreasonable...
And you don't need your umlauts and accents. The commands are all composed of ASCII characters.
... but the filenames aren't. When you're trying to free up vital disk space by deleting hügë_fïlë.jpg, wouldn't it be handy to be able to type its filename?
Re: (Score:2)
I can imagine some sneaky user putting a huge file in and spelling it with homoglyphs, just to annoy the admins. Added bonus if you find a way to mess with GUI tools too - eg, placing two files with the same name in different case in a folder where the admin habitually uses Windows to modify it.
Re: (Score:2)
Re: (Score: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.
At least some keyboard layouts rearrange the ASCII letters as well, Germany, Austria, Switzerland Serbia, Montenegro, Croatia, Slovenia, Bosnia-Herzegovina, Hungary, France, Belgium and Lithuania at least - usually just a few letters. What is more important is that all sorts of things like parentheses, slashes, quotation marks, question marks, asterisk, equals sign, colon, semicolon, piping etc. all change places for a lot more countries like us here in Norway, because we've made room on the far right for
Introduction of KMSCON... (Score:2, Informative)
How about a more informative introduction [wordpress.com]? All of the concerns raised have been addressed. If only people would avail themselves of a more complete understanding before vehemently opposing any sort of change, the world would be a much better place. If not though, the least you could do is keep quiet if you refuse to inform yourself.
This isn't change for the sake of change; the present VT system is seriously lacking, and has been since its inception.
Not again. (Score:2)
Are *nix developers bored or something? As if the udev/systemd/initscripts changes weren't enough. What possible good can come from messing with TTY?
Things being around for a while doesn't make them automatically needing replacement. That's Windows logic.
Oh well, there'll always be sensible fork.
The damage is already done. (Score:2)
My normally headless file server has a low-end nVidia card in it. This machine has no GUI, just the text console.
Video output of the text console on this machine does not work without installing the proprietary nVidia drivers. I just get garbled noise on the screen otherwise. This boggled my mind. It's a bug in the Nouveau drivers the kernel loads by default, of course, but the fact that video card driver bugs were preventing me from using the machine's text console...
It turns out that at some point the lin
QNX does this and gets it right. (Score:5, Informative)
QNX, the real-time message passing operating system now owned by Blackberry, does all "console" handling in user space. They've done that for years. That's because, in the embedded world, you can't assume the target machine has a console, or even a serial port.
When you build a QNX boot image for an embedded system, you can add any programs you want to be available as soon as the system boots. All device drivers are in user space, so that's how the initial set of drivers gets loaded. You can also load applications that way. Having a file system is optional. If necessary, all software can be in a ROM. This allows scaling down to small embedded devices.
A serial console program is available, and is loaded into most systems that have a serial port. There are other options for systems that don't have a serial port, like connecting it to a network.
There's also a system logger. It's common to have the system logger log to some network destination elsewhere, so problems out at Pumping Station 42 are reported to the control center far away.
Linux has tried to emulate this architecture. More drivers are in user space. But in Linux that was an afterthought, and it shows.
Re: (Score:2)
A fancy console would be nice as long as you can fall back to the old one. I'd hate to be locked out of a systems because some random video driver issue, font issue, unicode issue, or input device issue broke the new one.
It can already fail for such reason.
However what could change is that the userspace console process could be killed by the OOM Killer.
Also make sure you're not dupilcating effort. If you're going to put the console in userland anyway, maybe make is share bits with your GUI.
There is effectively some potiential for better integration. What about a console running over Wayland?
Re: (Score:2)
I'm guessing it has not changed much because it's simple well understood.
RTFA: "it's a user-interface in kernel-space, the code is poorly maintained, handles keyboards badly [...]"
Re: (Score:3)
Slashdot: News for Luddites, stuff that scares us.