Announcement

Collapse
No announcement yet.

Linux 5.2 Kernel To Introduce A Generic Counter Interface

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

  • Linux 5.2 Kernel To Introduce A Generic Counter Interface

    Phoronix: Linux 5.2 Kernel To Introduce A Generic Counter Interface

    Queued now into staging for introduction with the upcoming Linux 5.2 kernel cycle is a Generic Counter Interface to allow counter devices/drivers to re-use this common code rather than having to implement redundant code into each of these drivers...

    http://www.phoronix.com/scan.php?pag...neric-Counters

  • #2
    It would be amazing if one of the kernel releases had less lines of code than previous on. But I don't think that will ever happen.

    Comment


    • #3
      Sounds interesting and useful...also sounds like another way for Samsung to get KNOX counts.

      When I read the last paragraph, I thought it said Geiger Counter code and my first thought was "Cool, but really I hope I don't have to ever use that code".

      Comment


      • #4
        Which is the benefit of this innovation?

        Comment


        • #5
          Originally posted by Azrael5 View Post
          Which is the benefit of this innovation?
          To reduce duplicated code implemented in multiple places. That's literally the entirety of the first paragraph of the article.

          Comment


          • #6
            Originally posted by JacekJagosz View Post
            It would be amazing if one of the kernel releases had less lines of code than previous on. But I don't think that will ever happen.
            Most lines of code are for drivers / device support. Do you really want to drop support for some hardware?

            Comment


            • #7
              Originally posted by George99 View Post

              Most lines of code are for drivers / device support. Do you really want to drop support for some hardware?
              Refactoring enough code to make the line count difference negative across releases doesn't require removing features. Generally speaking, less code means better code, at least to some extent. Keep in mind that someone has to maintain all these lines, and that job becomes harder with every added driver.

              Comment


              • #8
                Originally posted by skeevy420 View Post

                To reduce duplicated code implemented in multiple places. That's literally the entirety of the first paragraph of the article.
                Which is the problem on duplication?

                Comment


                • #9
                  Originally posted by Azrael5 View Post

                  Which is the problem on duplication?
                  Apparently every driver that needs one implements its own counting system. This gives every driver a common counting framework. Pulling some modules out of my ass here, it would allow AMDGPU & XFS can use the same counting code instead of implementing it on their own separately leading to two counting frameworks within the kernel...now think in terms of how many drivers could be doing that independently already and that's a lot of duplicated efforts...

                  Comment


                  • #10
                    Originally posted by skeevy420 View Post

                    Apparently every driver that needs one implements its own counting system. This gives every driver a common counting framework. Pulling some modules out of my ass here, it would allow AMDGPU & XFS can use the same counting code instead of implementing it on their own separately leading to two counting frameworks within the kernel...now think in terms of how many drivers could be doing that independently already and that's a lot of duplicated efforts...
                    Many thanks, this issue could cause crashes?

                    Comment

                    Working...
                    X