Announcement

Collapse
No announcement yet.

Linux Sees A New Attempt At Threaded Console Printing

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

  • Linux Sees A New Attempt At Threaded Console Printing

    Phoronix: Linux Sees A New Attempt At Threaded Console Printing

    As part of the multi-year effort to overhaul the Linux kernel's printk() code there has been much work in recent months around threaded console printing so each registered console would have a kernel thread and console printing would be decoupled from the printk() callers. That work was aimed for Linux 5.19 but then reverted due to troubles. There is now a new implementation in the works...

    https://www.phoronix.com/news/New-Li...-Threaded-Work

  • #2
    I don't understand why they're not reintroducing a scrollback buffer now that they're already knee deep into rewriting console.h's buffer code and the likes... Why... :/

    Comment


    • #3
      Originally posted by c117152 View Post
      I don't understand why they're not reintroducing a scroll back buffer now that they're already knee deep into rewriting console.h's buffer code and the likes... Why... :/
      https://lwn.net/Articles/881827/
      The scroll back buffer is outside the printk to console stuff. console.h straight buffering code for output has never had anything todo with the scroll backbuffer. Console buffering for printk and the like is more of a ring buffer.

      Scroll back buffer is functionality of the console driver itself if it happens to support it.

      c117152 think about all the extra locking you would cause with a global scroll back buffer. Yes if your only console output off a device is going out a serial port that goes to storage there is no need for the kernel to have scrollback buffer as well.

      Console.h buffer code is how to get the data to all the consoles. Not the place for user-friendly stuff like scroll back buffers.

      Comment


      • #4
        There needs to be a totally new console. Something modern, Unicode aware, hardware accel, etc.

        Comment


        • #5
          I encountered some of the early issues with threaded console support, and despite it breaking some things for me I came away severely impressed.
          The main issue I have (and I'm unsure of how they could realistically fix it) is when the kernel dies, the buffer just stops printing. It makes debugging embedded systems rather difficult. I hope this new series has fixed the issues we ran into.

          Comment


          • #6
            This takes me back to my IBM series 1 days. When had a printer attached to my series 1. In those days print(k) was hard wired out of the processor. Now I wonder if they are coding these extra print(k) sets of code on a per core basis. Can someone set me straight.

            Comment


            • #7
              Originally posted by scottishduck View Post
              There needs to be a totally new console. Something modern, Unicode aware, hardware accel, etc.
              Like kmscon?

              Comment


              • #8
                Originally posted by scottishduck View Post
                There needs to be a totally new console. Something modern, Unicode aware, hardware accel, etc.
                Originally posted by intelfx View Post
                Like kmscon?
                There is consoled in systemd source package that most distributions don't build or provide that was to be newer version of kmscon that end up not happening..

                Comment


                • #9
                  From the mailing list replies, this new patches seems to contains a well designed approach to the threaded printing, Linus haven't said anything bad about the patches, so this is good

                  Comment


                  • #10
                    Originally posted by oiaohm View Post

                    https://lwn.net/Articles/881827/
                    The scroll back buffer is outside the printk to console stuff. console.h straight buffering code for output has never had anything todo with the scroll backbuffer. Console buffering for printk and the like is more of a ring buffer.

                    Scroll back buffer is functionality of the console driver itself if it happens to support it.

                    c117152 think about all the extra locking you would cause with a global scroll back buffer. Yes if your only console output off a device is going out a serial port that goes to storage there is no need for the kernel to have scrollback buffer as well.

                    Console.h buffer code is how to get the data to all the consoles. Not the place for user-friendly stuff like scroll back buffers.
                    But that's only how things used to be. Now that they're already changing the lower level buffers they can just throw in a backbuffer and a lock-less copy into an additional dedicated scrollback buffer like how lock-less screen capture for streaming works. It's common practice in graphics.

                    Comment

                    Working...
                    X