Announcement

Collapse
No announcement yet.

The State Of Killing CONFIG_VT, Moving To User-Space

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

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

    Comment


    • #17
      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

      Comment


      • #18
        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!

        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

        Comment


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

          Comment


          • #20
            Maybe I got that wrong and confused VTs with TTYs.
            @Ericg: Busybox uses mdev, it also has its own init implementation, but I usually don't use that, since I don't have a need for runlevels and stuff, I use a custom script (running in ash, which also comes with Busybox) for initializing all of the system I need and do the tasks I need to do.
            If this is still working without having to add unnecessary complexity with this new approach, then I got this wrong and apologize. If this is not anymore possible it would be a shame.

            Comment


            • #21
              Originally posted by Vim_User View Post
              Maybe I got that wrong and confused VTs with TTYs.
              @Ericg: Busybox uses mdev, it also has its own init implementation, but I usually don't use that, since I don't have a need for runlevels and stuff, I use a custom script (running in ash, which also comes with Busybox) for initializing all of the system I need and do the tasks I need to do.
              If this is still working without having to add unnecessary complexity with this new approach, then I got this wrong and apologize. If this is not anymore possible it would be a shame.
              Whats busybox gonna do when udev is moved back in kernel? Seems like that would conflict with mdev at that point...

              Comment


              • #22
                Originally posted by Ericg View Post
                Whats busybox gonna do when udev is moved back in kernel? Seems like that would conflict with mdev at that point...
                How could udev possibly be moved "back" in to the kernel? It's userspace daemon with various dependencies like glibc and kmod. If someone were to fork systemd-udev it would really make no difference. systemd based distributions would still use systemd-udev, Android would still use their implementation and nothing would change for mdev ...and who exactly is supposed to maintain this alleged udev fork? It seems all major udev developers very a-ok with the systemd merge.

                Comment


                • #23
                  Originally posted by Teho View Post
                  How could udev possibly be moved "back" in to the kernel? It's userspace daemon with various dependencies like glibc and kmod. If someone were to fork systemd-udev it would really make no difference. systemd based distributions would still use systemd-udev, Android would still use their implementation and nothing would change for mdev ...and who exactly is supposed to maintain this alleged udev fork? It seems all major udev developers very a-ok with the systemd merge.
                  back is bad wording on my part, but the topic of in-kernel udev came up back when the topic of in-kernel dbus came up. I don't know what ever came from that discussion (it was a dev who brought it up), I'm trying to track it down now.

                  Comment


                  • #24
                    Originally posted by Ericg View Post
                    back is bad wording on my part, but the topic of in-kernel udev came up back when the topic of in-kernel dbus came up. I don't know what ever came from that discussion (it was a dev who brought it up), I'm trying to track it down now.
                    I do remember that conversation.

                    Comment


                    • #25
                      Originally posted by duby229 View Post
                      I do remember that conversation.
                      Okay at least I know I'm not going crazy XD

                      Comment


                      • #26
                        Originally posted by Teho View Post
                        How could udev possibly be moved "back" in to the kernel? It's userspace daemon with various dependencies like glibc and kmod. If someone were to fork systemd-udev it would really make no difference. systemd based distributions would still use systemd-udev, Android would still use their implementation and nothing would change for mdev ...and who exactly is supposed to maintain this alleged udev fork? It seems all major udev developers very a-ok with the systemd merge.
                        eudev is still in good shape, the last commits only happened several days ago.

                        Comment


                        • #27
                          Originally posted by M1kkko View Post
                          The more I think about this, the more stupid it sounds.
                          Aye! Its a an answer in search of a question that was never asked. But knowing Red Hat you will see in Fedora soon.

                          Comment

                          Working...
                          X