Announcement

Collapse
No announcement yet.

DRM Kernel Log Renderer Proposed For Linux

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

  • DRM Kernel Log Renderer Proposed For Linux

    Phoronix: DRM Kernel Log Renderer Proposed For Linux

    One of the long-standing proclaimed benefits of Direct Rendering Manager (DRM) graphics drivers for the Linux kernel was that it would be possible to have "Blue Screen of Death"-like error messages in cases of kernel issues. That feature is now closer to being realized while also advancing another goal of disabling VT support within the Linux kernel...

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

  • #2
    I gather they're saying "no text during boot or shutdown/crash". What am I missing? Because that can't be what they're saying.

    Comment


    • #3
      Originally posted by xeekei View Post
      I gather they're saying "no text during boot or shutdown/crash". What am I missing? Because that can't be what they're saying.
      No, what they're saying is "If you disable VT's and do nothing else, you wont get debug info from Kernel Oops" (also some DE's apparently fail to load, who knew) because the VT subsystem registers a "console-driver" that can accept the crash output to display as text. If you're looking to replace or deprecate the VT subsystem then its important to have something else which handles all the important stuff the VT's did, this being one of those features. Enter drm-kernel-log, it registers a replacement console-driver so that you still get crash output from the kernel once a crash happens, even if the VT's are disabled.

      Comment


      • #4
        So, the "Blue Screen Of Death" is considered a feature now? In that case, Linux should make its version purple. We don't want to copy "features" verbatim after all.

        Comment


        • #5
          Originally posted by CTown View Post
          So, the "Blue Screen Of Death" is considered a feature now? In that case, Linux should make its version purple. We don't want to copy "features" verbatim after all.
          A longer and more detailed (or at least more text thats visible) crash output is a feature. Also, as I said above, its an issue of feature-parity.

          Comment


          • #6
            Why would you want the VT be disabled? As I understand disabling the VT subsystem will disable the ability to use TTY's? Correct me if I'm wrong!

            Comment


            • #7
              Originally posted by BSDude View Post
              Why would you want the VT be disabled? As I understand disabling the VT subsystem will disable the ability to use TTY's? Correct me if I'm wrong!
              Yeah, I think you're right, mostly, and this led to my initial thought of protest. *However*, they seem not only to want to disable VT's but replace them, see "Combined with a proper user-space system-console". Technically it would be pretty interesting if VT-like functionality could be implemented completely in user-space using KMS. That way in-kernel functionality would simplify a lot and you might even get the accelerated non-graphical terminals back for free. (afaik currently VT's under KMS aren't properly accelerated which you typically don't notice if you use it for text only)

              Comment


              • #8
                Originally posted by BSDude View Post
                Why would you want the VT be disabled? As I understand disabling the VT subsystem will disable the ability to use TTY's? Correct me if I'm wrong!

                Why would you want the VTs and TTYs enabled on :
                - phones ?
                - TV DivX / etc.. players ?
                - Google glasses ?
                - Steamboxes ?
                - Car IVI systems ?
                - Smart watch ?
                - Any kind of hardware that doesn't have a keyboard and runs under Linux, i.e. certainly most of the linux ecosystem ?

                Comment


                • #9
                  Originally posted by BSDude View Post
                  Why would you want the VT be disabled? As I understand disabling the VT subsystem will disable the ability to use TTY's? Correct me if I'm wrong!
                  I've heard that the VT code is somewhat limited, hard to maintain, doesn't support complex writing systems and doesn't fit very well with other modern kernel subsystems. However, from a user's point of view, VTs do work, they're easy to use, reliable, and they allow you to fix stuff without external help.

                  Comment


                  • #10
                    Originally posted by peppepz View Post
                    I've heard that the VT code is somewhat limited, hard to maintain, doesn't support complex writing systems and doesn't fit very well with other modern kernel subsystems. However, from a user's point of view, VTs do work, they're easy to use, reliable, and they allow you to fix stuff without external help.
                    VT switch is somewhat less reliable than people think if you have anything that uses graphics mode (since in that case VT switch becomes a cooperative thing between outgoing and incoming VT.. if the thing you are trying to switch away from is in a bad state (or in a breakpoint in gdb, etc).. well, opps, sorry, it won't work.

                    Comment


                    • #11
                      Originally posted by nanonyme View Post
                      Yeah, I think you're right, mostly, and this led to my initial thought of protest. *However*, they seem not only to want to disable VT's but replace them, see "Combined with a proper user-space system-console". Technically it would be pretty interesting if VT-like functionality could be implemented completely in user-space using KMS. That way in-kernel functionality would simplify a lot and you might even get the accelerated non-graphical terminals back for free. (afaik currently VT's under KMS aren't properly accelerated which you typically don't notice if you use it for text only)
                      That's exactly what KMSCON does, and it was written by the same author. It's a hardware-accelerated terminal with support for Unicode, internationalized keyboard support, video acceleration via OpenGL ES 2 and scalable fonts. It works without KMS support too, so it's a full replacement for this kernel code with the new log driver.

                      Comment


                      • #12
                        Originally posted by strcat View Post
                        That's exactly what KMSCON does, and it was written by the same author.
                        Altough true I think he's not going to work on KMSCON anymore. He did write systemd-consoled that's still work in-progress which could well become the default in many distributions in the future.

                        ..duplicate kmscon?

                        Well, I wrote that and I consider it a successfull research project. Now
                        it's time to write something useful based on the lessons learned with
                        kmscon. No first attempt ever succeeds, right?

                        Comment


                        • #13
                          Really good series of articles David wrote a while back on why we should be killing off the VT and session management: https://dvdhrm.wordpress.com/2013/08...ment-on-linux/

                          Comment


                          • #14
                            Originally posted by Ericg View Post
                            A longer and more detailed (or at least more text thats visible) crash output is a feature. Also, as I said above, its an issue of feature-parity.
                            I was only kidding! But thanks for the explanation.

                            Comment

                            Working...
                            X