Announcement

Collapse
No announcement yet.

Systemd 217 Will Introduce Its New "Consoled" User Console Daemon

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Systemd 217 Will Introduce Its New "Consoled" User Console Daemon

    Phoronix: Systemd 217 Will Introduce Its New "Consoled" User Console Daemon

    Back in August I wrote about systemd working to create a new user-space VT solution that could eventually succeed the Linux kernel's VT support. With the upcoming systemd 217 release, the terminal is present...

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

  • #2
    Why?

    Can someone tell me what is the impulse for this?

    Comment


    • #3
      Originally posted by danieru View Post
      Can someone tell me what is the impulse for this?
      CONFIG_VT is extremely complicated, and whenever someone tries to fix a bug they usually end up creating 2 new ones.

      The idea is to get rid of it, while simultaneously bring in new features and things that weren't possible with the old system.

      Comment


      • #4
        Originally posted by danieru View Post
        Can someone tell me what is the impulse for this?
        Read some of the links to previous Phoronix articles for details, but the gist of it is that the console is a big piece of code which sits in the kernel, and which would (arguably) be pulled out to userspace. The reasons are essentially that a) a terminal emulator is a big complicated thing to be running inside the kernel, and b) because of the constraints of running inside the kernel, it's not a very good terminal emulator.

        The flip side is of course that the console is a fairly important component when things go wrong, and having it built into the kernel takes away a potentially brittle integration point...

        Comment


        • #5
          Originally posted by Delgarde View Post
          The flip side is of course that the console is a fairly important component when things go wrong, and having it built into the kernel takes away a potentially brittle integration point...
          To an extent, yes, but remember that the shell you are actually using to DO anything "when things go wrong" is in userspace. So there's no guarantee that you can actually login or even execute commands in said console.

          Comment


          • #6
            Originally posted by Ericg View Post
            To an extent, yes, but remember that the shell you are actually using to DO anything "when things go wrong" is in userspace. So there's no guarantee that you can actually login or even execute commands in said console.
            Sure, and personally, I'm happy with the changes they're making. I just mentioned the "flip side" as context for why it's a little contentious.

            Comment


            • #7
              Originally posted by smitty3268 View Post
              CONFIG_VT is extremely complicated, and whenever someone tries to fix a bug they usually end up creating 2 new ones.

              The idea is to get rid of it, while simultaneously bring in new features and things that weren't possible with the old system.
              Originally posted by Delgarde View Post
              Read some of the links to previous Phoronix articles for details, but the gist of it is that the console is a big piece of code which sits in the kernel, and which would (arguably) be pulled out to userspace. The reasons are essentially that a) a terminal emulator is a big complicated thing to be running inside the kernel, and b) because of the constraints of running inside the kernel, it's not a very good terminal emulator.

              The flip side is of course that the console is a fairly important component when things go wrong, and having it built into the kernel takes away a potentially brittle integration point...
              Thanks

              Comment


              • #8
                good thing: this will probably will make things better related to the console daemon.
                not a good thing: another thing under the control (and dependent) of systemd.
                At least that's what I understood.

                Comment


                • #9
                  Originally posted by edoantonioco View Post
                  good thing: this will probably will make things better related to the console daemon.
                  not a good thing: another thing under the control (and dependent) of systemd.
                  At least that's what I understood.
                  systemd is the future and technically that's what the consoled should be spawned off. Deal with it.

                  Comment


                  • #10
                    Originally posted by edoantonioco View Post
                    good thing: this will probably will make things better related to the console daemon.
                    not a good thing: another thing under the control (and dependent) of systemd.
                    At least that's what I understood.
                    Correction. Is a good thing, that is under the control of a init system, seriously; I don't see any other point where it would make sense to put a user-accessible console subsystem other than when the kernel starts (the current) or when the user-space/init daemon setups most of the system, by that, it could be anywhere after init, but if I were to choose, I still prefer any init daemon, including systemd, managing it.

                    Comment

                    Working...
                    X