Page 1 of 2 12 LastLast
Results 1 to 10 of 26

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

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,390

    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
    963

    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
    140

    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.

  4. #4
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,738

    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.
    As far as whether you will be forced to use logind... no. If you actually read the article carefully one of the very first paragraphs states (and this has been re-iterated by other developers for similar situations) logind is becoming the defacto implementation of session management on the linux desktop. Does this mean you have to use logind? No. IF someone wants to come around and not use logind because they dont want to use systemd and they start to write their own session manager, thats fine. The only thing that will be required of them is to support the baseline logind API so that programs higher-up than the session manager dont have to actually worry about what the session manager IS. (No testing to see what session manager is in use and then using foo.bar.login(); and if using logind use logind.login(); its all just: login(); )

    Early level kernel panic? Serial Console. As ALWAYS, this has never changed since Linux's inception. Also like 99% of kernel config options... I see no reason why instead of as a module, the fblog and drmlog kernel pieces couldnt instead be built right into the kernel, ensuring that they are always active. initrd could at minimum load them-- and lets be honest, if your initrd is fscked, then youve got bigger problems and we're probably back to "A serial console is the only thing thats gonna help you"

    Its killing off kernel components because they suck and kernelspace in general sucks and no one wants to code in kernel space if they can help it.
    Last edited by Ericg; 07-09-2013 at 11:01 AM.

  5. #5
    Join Date
    Jan 2013
    Posts
    963

    Default

    Quote Originally Posted by Ericg View Post
    As far as whether you will be forced to use logind... no. If you actually read the article carefully one of the very first paragraphs states (and this has been re-iterated by other developers for similar situations) logind is becoming the defacto implementation of session management on the linux desktop. Does this mean you have to use logind? No. IF someone wants to come around and not use logind because they dont want to use systemd and they start to write their own session manager, thats fine. The only thing that will be required of them is to support the baseline logind API so that programs higher-up than the session manager dont have to actually worry about what the session manager IS. (No testing to see what session manager is in use and then using foo.bar.login(); and if using logind use logind.login(); its all just: login(); ).
    And you totally missed the point. I don't need session management for a single purpose system that runs a specific script in Busybox from an initrd. But what I need is input and output, without having to do any magic or even writing a session manager just to see something.
    Again, I am not talking about desktop systems, but there seem to be some developers that think Linux is all about desktop systems.
    So I have to ask again, how will this affect me, when this becomes the standard and sometime in the future the old VTs become unmaintained or even removed?
    It seems to me that there is a rush for "new" where it isn't necessary.

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,738

    Default

    Quote Originally Posted by Vim_User View Post
    And you totally missed the point. I don't need session management for a single purpose system that runs a specific script in Busybox from an initrd. But what I need is input and output, without having to do any magic or even writing a session manager just to see something.
    Again, I am not talking about desktop systems, but there seem to be some developers that think Linux is all about desktop systems.
    So I have to ask again, how will this affect me, when this becomes the standard and sometime in the future the old VTs become unmaintained or even removed?
    It seems to me that there is a rush for "new" where it isn't necessary.
    What do you use NOW to control it and to control init? (I havent worked with BusyBox myself so they may their own solution) SysV? For something that specialized I really doubt that anything the rest of the Linux ecosystem does will affect you unless it involves the kernel.

    Yes, Config_VT will probably be unmaintained and removed eventually.. In which case you are left with kmscon, yes, but kmscon doesn't rely on systemd it just uses it if its available and configured to. Kmscon only REQUIRES udev and XKCB, both of which you should have even on a busybox system I would think. The KMSCON readme on github even states

    If you want only a very basic kmscon program without any major dependencies, use:
    $ ./configure --with-video=fbdev,drm2d --with-renderers= --with-fonts=unifont --disable-multi-seat --with-sessions=dummy,terminal
    Again, I just don't see what you are complaining about. Something THAT specific is only gonna be really affected by kernel work (which, admittedly, the removal of VT IS kernel work, but see the text above)

    Also if you talked to the devs about what is WRONG with the VT work... you'd know. Its a code-abortion as far as stability, maintainability and reliability-- everything that you SHOULDNT be able to use to describe in-kernel code

  7. #7
    Join Date
    Mar 2012
    Posts
    13

    Default

    Quote Originally Posted by Vim_User View Post
    And you totally missed the point. I don't need session management for a single purpose system that runs a specific script in Busybox from an initrd. But what I need is input and output, without having to do any magic or even writing a session manager just to see something.
    Again, I am not talking about desktop systems, but there seem to be some developers that think Linux is all about desktop systems.
    First of all, TTYs will not get removed! You can always get input/output via TTYs. Moreover, VTs will also stay! I'd like to see them removed, but as the article states at the beginning, it's not about removing VTs but supporting situations where VTs are not available.

    And if you'd read the article, right upfront it tells you it's only about desktop systems. If you don't use a desktop system, please feel free to ignore it! It doesn't affect you in any way!

    Quote Originally Posted by Vim_User View Post
    So I have to ask again, how will this affect me, when this becomes the standard and sometime in the future the old VTs become unmaintained or even removed?
    It seems to me that there is a rush for "new" where it isn't necessary.
    VTs haven't seen any proper maintenance for years! So please don't tell anyone you fear the day where VTs will be no longer developed. Because then you fear the present day!
    And as usual: No kernel API gets removed! Never! Ever! As long as any used user-space program relies on it.

    Cheers
    David

  8. #8
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,738

    Default

    Quote Originally Posted by dvdhrm View Post
    Cheers
    David
    Was wondering when you'd show up haha, welcome back to the forums David :P

  9. #9
    Join Date
    Mar 2013
    Posts
    140

    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.

  10. #10
    Join Date
    Jan 2009
    Posts
    189

    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.

Posting Permissions

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