Forgot your password?
typodupeerror
Linux

Moving the Linux Kernel Console To User-Space 311

Posted by Soulskill
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."
This discussion has been archived. No new comments can be posted.

Moving the Linux Kernel Console To User-Space

Comments Filter:
  • why? (Score:2, Insightful)

    by andjeng (2799457)
    if something have any purpose, why should we kill it?
    • by andjeng (2799457)
      and serving its purpose decently, offcourse.
      • Off-course like the Costa Concordia?
      • Re:why? (Score:5, Insightful)

        by Anonymous Coward on Friday February 08, 2013 @12:40PM (#42833479)

        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? (Score:5, Informative)

      by Anonymous Coward on Friday February 08, 2013 @11:27AM (#42832423)

      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)

        by Anonymous Coward on Friday February 08, 2013 @11:45AM (#42832665)

        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)

          by jedidiah (1196)

          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)

            by Anonymous Coward on Friday February 08, 2013 @12:56PM (#42833731)

            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.

            • Only if you ignore that the basic console has been stable for how many years/decades?
            • Re:why? (Score:4, Insightful)

              by fa2k (881632) <{pmbjornstad} {at} {gmail.com}> on Friday February 08, 2013 @05:04PM (#42837161)

              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, Interesting)

          by tibit (1762298) on Friday February 08, 2013 @03:37PM (#42835997)

          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)

            by Hatta (162192) on Friday February 08, 2013 @04:14PM (#42836491) Journal

            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?

          • by epyT-R (613989)

            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)

        by Hatta (162192) on Friday February 08, 2013 @12:31PM (#42833345) Journal

        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)

        by Spazmania (174582) on Friday February 08, 2013 @01:58PM (#42834621) Homepage

        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)

    by Anonymous Coward on Friday February 08, 2013 @11:17AM (#42832305)

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

    • Re:Unneeded (Score:4, Insightful)

      by Anonymous Coward on Friday February 08, 2013 @11:48AM (#42832707)

      100x This ^^^

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

    • by dolmen.fr (583400)

      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.

    • by Skapare (16644)

      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

      • Note that cooked line input is not part of the "console", it's part of the tty system.

      • by ultranova (717540)

        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.

        Which is very useful for troublesolving.

  • good thinking HA! (Score:5, Insightful)

    by rubycodez (864176) on Friday February 08, 2013 @11:21AM (#42832349)

    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

    • by Anonymous Coward on Friday February 08, 2013 @11:25AM (#42832401)
      This could be an essential part of GNOME 3!
    • 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.
    • by Jawnn (445279)

      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.

    • by Skapare (16644)

      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.

    • by rubycodez (864176)

      had funny thought, this might work in MINIX kernel architecture, but not monolithic one

    • by Marillion (33728)

      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

  • by Anonymous Coward on Friday February 08, 2013 @11:21AM (#42832353)

    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 (Score:2, Insightful)

    by Anonymous Coward

    If it works, don't fix it

  • by Anonymous Coward on Friday February 08, 2013 @11:25AM (#42832399)

    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.

    • by ArsonSmith (13997)

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

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

      • In development/in innovation you have to look at everything and think, "can it be better?"

        And that's fine, as long as you accept that at least sometimes, the answer is "No."

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

  • by Anonymous Coward on Friday February 08, 2013 @11:35AM (#42832529)

    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)

    by christurkel (520220) on Friday February 08, 2013 @11:37AM (#42832545) Homepage Journal
    a hardware-accelerated console

    Why?
    • by EnsilZah (575600)

      Multitouch onscreen keyboard in Stereoscopic 3D, it's like, the future, man.

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

    • by rrohbeck (944847)

      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.

  • When I read "a hardware-accelerated console" I though that it must be a joke. This whole story.
    Bravo! He made it on /. headlines...
    (otherwise this kind of idea could have made me feel quite anxious)

    • by ultrasawblade (2105922) on Friday February 08, 2013 @12:28PM (#42833313)

      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.

      • by rrohbeck (944847)

        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.

      • Wellll, actually, it's doing that, but the BIOS software is emulating the legacy behavior you see.

    • by KiloByte (825081)

      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.

  • by xonen (774419) on Friday February 08, 2013 @11:56AM (#42832815) Journal

    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.

  • by fnj (64210) on Friday February 08, 2013 @11:58AM (#42832845)

    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)

      by PRMan (959735)
      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.
    • by drinkypoo (153816)

      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.

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

  • by ultrasawblade (2105922) on Friday February 08, 2013 @12:27PM (#42833289)

    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.

  • by idontgno (624372) on Friday February 08, 2013 @12:28PM (#42833321) Journal

    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.
    • by psmears (629712) on Friday February 08, 2013 @01:02PM (#42833809)

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

    • by Kjella (173770)

      "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

  • by Anonymous Coward

    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.

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

  • 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

  • by Animats (122034) on Friday February 08, 2013 @03:25PM (#42835803) Homepage

    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.

The F-15 Eagle: If it's up, we'll shoot it down. If it's down, we'll blow it up. -- A McDonnel-Douglas ad from a few years ago

Working...