Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: The State Of Killing CONFIG_VT, Moving To User-Space

  1. #1
    Join Date
    Jan 2007
    Posts
    14,621

    Default The State Of Killing CONFIG_VT, Moving To User-Space

    Phoronix: The State Of Killing CONFIG_VT, Moving To User-Space

    David Herrmann is a student developer and one of the kernel developers that has been on a mission to kill off CONFIG_VT, a.k.a. the VT console within the Linux kernel, and move it off to user-space. He's contributed to various projects to further his ideas and now he's written a new post to provide an update on this matter and his thoughts on the current situation of Linux system compositors...

    http://www.phoronix.com/vr.php?view=MTQwNTk

  2. #2
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    So what does that mean for people like me that like to implement single purpose systems, using Busybox running from an initrd? Do we have to use systemd, bloating and complicating our systems only to see output on the screen and have user input? What happens when the kernel panics before it is able to load one of those log modules? Will we ever know what happened?
    I don't get why this developers try to kill off kernel components with only desktop systems in mind. Hello, welcome to reality, the largest install base of Linux is on Android devices, no systemd there, so no, systemd/logind is by far not the standard session handler.

  3. #3
    Join Date
    Mar 2013
    Posts
    144

    Default

    Is "Only one desktop session is active at a time!" means what I think it means ? So, I won't be able to have two window managers, and\or XBMC running at the same time? That's no good.
    We've been seeing more and more only-in-gnome or only-in-unity programs and functionality recently (wifi anyone?). And, while it shouldn't be the case, as more and more functionality is moved away from the CLI and isn't integrated into some generic GUI program (and is rather made a gnome extension and the likes), we're becoming dependent on those window managers...

    And I can't help think about the future here. There are mobile platforms coming along where a window manager might be the only difference between them and a linux desktop. A developer would definitely be interested in having one such session running concurrently to his own without extra hardware instead of some virtual machine. Writing a few lines, compiling, switching with ALTCTRLF7, running and testing stuff, switching back... It's a work flow worth keeping.

  4. #4
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote Originally Posted by Vim_User View Post
    So what does that mean for people like me that like to implement single purpose systems, using Busybox running from an initrd? Do we have to use systemd, bloating and complicating our systems only to see output on the screen and have user input? What happens when the kernel panics before it is able to load one of those log modules? Will we ever know what happened?
    I don't get why this developers try to kill off kernel components with only desktop systems in mind. Hello, welcome to reality, the largest install base of Linux is on Android devices, no systemd there, so no, systemd/logind is by far not the standard session handler.
    I think he mentioned CONFIG_VT will stay available. As for kernel panic, it will likely dump and reboot, which is what most of us do anyhow As for Android, I think Google can take care of itself Besides, they rarely upstream their fork changes to Linus's main branch so if something gets broken, it's Google's responsibility to fix it. Though, in this case I don't think they'll be having any issues. Tizen has Wayland and systemd so it's impossible for Google to follow suit.

  5. #5
    Join Date
    Jan 2009
    Posts
    191

    Default

    Quote Originally Posted by c117152 View Post
    Is "Only one desktop session is active at a time!" means what I think it means ? So, I won't be able to have two window managers, and\or XBMC running at the same time? That's no good.
    We've been seeing more and more only-in-gnome or only-in-unity programs and functionality recently (wifi anyone?). And, while it shouldn't be the case, as more and more functionality is moved away from the CLI and isn't integrated into some generic GUI program (and is rather made a gnome extension and the likes), we're becoming dependent on those window managers...

    And I can't help think about the future here. There are mobile platforms coming along where a window manager might be the only difference between them and a linux desktop. A developer would definitely be interested in having one such session running concurrently to his own without extra hardware instead of some virtual machine. Writing a few lines, compiling, switching with ALTCTRLF7, running and testing stuff, switching back... It's a work flow worth keeping.
    i second that. Linux-systems are the pinnacle of multi-user & multi-session usability, but many of those recent redesigns are fucking it up.
    i like what this guy is doing, but i hope that he will not fuck that up even further, dammit.

  6. #6
    Join Date
    Jul 2009
    Posts
    250

    Default

    i really have no clue but could it be this will end up like UMS vs KMS?
    - lets get all the stuff out of the kernel...
    10 years later:
    - lets get it back into the kernel

    why killing kernel console again.?
    number one priority should be reliability (with no excuse) shouldnt it?

  7. #7
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote Originally Posted by jakubo View Post
    why killing kernel console again.?
    Because it sucks.

    Quote Originally Posted by jakubo View Post
    i really have no clue but could it be this will end up like UMS vs KMS?
    It will never be removed from the kernel because it would break compatibility. I wouldn't be suprised if distribution started shipping with CONFIG_VT=n in couple of years though because KMSCON is better than linux console in virtually every respect. Linux console will never be improved so that will not exactly change either.

    i like what this guy is doing, but i hope that he will not fuck that up even further, dammit.
    The idea is to _improve_ it.

    No multi-seat capabilities: The VT system is highly incompatible with multi-seat environments. Current multi-seat implementations simply bind all VTs to the default-seat (or “seat0″) and all other seats just ignore all VTs. Therefore, you can think of all other seats already running with CONFIG_VT=n.
    --Source

  8. #8
    Join Date
    Mar 2011
    Posts
    213

    Default

    a mission to kill off CONFIG_VT, a.k.a. the VT console within the Linux kernel, and move it off to user-space.
    The more I think about this, the more stupid it sounds.

  9. #9
    Join Date
    Apr 2010
    Posts
    717

    Default

    Quote Originally Posted by c117152 View Post
    Is "Only one desktop session is active at a time!" means what I think it means ? So, I won't be able to have two window managers, and\or XBMC running at the same time? That's no good.
    I think the keyword is "active". You might have two window manager sessions running, but presumably they're not both rendering to the same screen simultaneously? Because that seems to be the definition of "active" the article is using - it's not saying you can't run different stuff on different VTs, it's saying that only one of them is controlling the screen at once.

  10. #10
    Join Date
    May 2010
    Posts
    122

    Default

    Quote Originally Posted by Delgarde View Post
    I think the keyword is "active". You might have two window manager sessions running, but presumably they're not both rendering to the same screen simultaneously? Because that seems to be the definition of "active" the article is using - it's not saying you can't run different stuff on different VTs, it's saying that only one of them is controlling the screen at once.
    Yes, you're right. This exact question was asked and answered in the article comments (with the same XBMC example):
    http://dvdhrm.wordpress.com/2013/07/...s/#comment-484
    What you want is exactly the setup described in the article. You have to know that “active” means “in foreground”. You can have as many sessions as you want, but only one of them can be _active_. Or how do you think multiple sessions can be active? You cannot share a monitor between sessions at a time.
    Switching between sessions will always be possible. So you can switch to XBMC, Weston, Xorg, Steam, console … whenever you want. (btw., steam doesn’t really belong in that least. Session management is at a lower level than that, but according to your description it has a 1-to-1 mapping so we could see it as session).

    The other concern people have is about the emergency use of VTs when their primary session locks up. That was addressed as well:
    http://dvdhrm.wordpress.com/2013/07/...s/#comment-477
    As Stephen already said, that is still possible. Having VT management in the kernel does allow reacting to keyboard events in interrupt handlers, however, you need at least a working bash to make use of an emergency console. And if bash can run, kmscon can run, too. In fact, the fbcon->fbdev->DRM layer is known to be fragile in those situations, so we could even end up with a more reliable emergency console.
    I know Michael was trying to help by only providing the conclusion, but a lot of the important things were discussed in this article and weren't reiterated or summarized in the conclusion.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •