Posted
by
Soulskill
on Friday February 08, 2013 @11:15AM
from the cuddly-console-seeks-loving-home dept.

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."

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 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.

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.

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.

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

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.

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.

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,

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.

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!

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.

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.

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

I just noticed an *LPT* port card is installed on my work desktop! What brain damage did my IT team have to think my.NET development workstation would have any reason for an *LPT* port! Just hilarious.

I generally agree although I also don't think it needs to be quite as sophisticated as it is. But that said, answering my own criticism, does supporting multiple character sets, colors, and screen sizes really add so much bloat it'd be worth stripping it down?

Seeing Linux in quite a number of embedded applications, I would say yes... also, just because it is in user mode, doesn't mean it has to be loaded with everything in user-space to be available at the core... It does make more advanced options available, and more easily swapped out, or removed altogether.

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.

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

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.

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.

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.

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.

Could you imagine actually having your terminal displayed in stereoscopic 3D? Watching your DMESG print up all sticking out 3 feet off your screen in your face. I totally disagree with what this dude is doing, but that aside; that would just be totally fucking cool.:D

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.

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.

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.

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.

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.

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.

Seriously. What's with this new generation that has to force their way or the highway on the world? Every new piece of software that comes out forces you to do things you don't want. Now they're trying to turn Linux into Windows 8.

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.

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.

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.

"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.

"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.

"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.

"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.

"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?

"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.

"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?

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.

Yes, I know, but the claim is that its keyboard handling is less than perfect. I don't know the details of that; I was merely making the point that "just use ASCII" isn't enough to mean you don't need to worry about keyboard mappings.

"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

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.

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...

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.

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?