Slashdot Mirror
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."
Lets not mess with the TTY's they are STILL NEEDED for when things go wrong...
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
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.
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.
This could be an essential part of GNOME 3!
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.
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.
a hardware-accelerated console
Why?
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
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.
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.
If it still works, you haven't fixed it enough.
Welcome to the Panopticon. Used to be a prison, now it's your home.
I think it should require Unity and a touchscreen
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.
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.
A Pirate and a Puritan look the same on a balance sheet.
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.
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.
From TFA (to save your delicate eyes from the indignity of RTFA):
Let's look at this one item at a time.
Welcome to the Panopticon. Used to be a prison, now it's your home.
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.
Give me Classic Slashdot or give me death!
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.
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.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
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.
A successful API design takes a mixture of software design and pedagogy.
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.
A successful API design takes a mixture of software design and pedagogy.
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?
Give me Classic Slashdot or give me death!
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
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!