Announcement

Collapse
No announcement yet.

The Extraordinary DRM Pull Request For Linux 3.11

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

  • The Extraordinary DRM Pull Request For Linux 3.11

    Phoronix: The Extraordinary DRM Pull Request For Linux 3.11

    David Airlie has submitted the DRM subsystem pull request for the Linux 3.11 kernel that is of monster size. The Radeon DRM kernel driver is now perhaps the single biggest Linux kernel driver by code size after the merging of its huge dynamic power management code addition...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Very big to boot ?

    By the sounds of it .. how do you fit such as big driver with the kernel updates, boot disks and distributions. I would love to see them have a basic core driver that is simple and small to get the computer started and then allows the system to load or swap drivers to enable playing games and advanced features. If it's done right we have the convenience of a small driver that is included everywhere and the user can then load the fancy stuff after the initial boot. Otherwise we are left with big packages and updates even before you can boot.

    Comment


    • #3
      Originally posted by tygrus View Post
      By the sounds of it .. how do you fit such as big driver with the kernel updates, boot disks and distributions. I would love to see them have a basic core driver that is simple and small to get the computer started and then allows the system to load or swap drivers to enable playing games and advanced features. If it's done right we have the convenience of a small driver that is included everywhere and the user can then load the fancy stuff after the initial boot. Otherwise we are left with big packages and updates even before you can boot.
      That is not a real issue, and even if it was what you're proposing is not a good solution because videocards in particular need proper power and fan management that a generic VESA driver can't handle.

      Comment


      • #4
        It's going to be fun to see Linus' response to this =)

        Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:

        Ask a programmer to review 10 lines of code, he'll find 10 issues. Ask him to do 500 lines and he'll say it looks good.

        Comment


        • #5
          Originally posted by Azpegath View Post
          It's going to be fun to see Linus' response to this =)

          Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:
          Well I doubt Linus will really care, its the merge window, he merges stuff that has been tested, and this code has seen a lot of testing already,

          The code has been reviewed by a number of people, granted the number of people who can make sense of gpu power management code is limited :-P

          Dave.

          Comment


          • #6
            Originally posted by airlied View Post
            Well I doubt Linus will really care, its the merge window, he merges stuff that has been tested, and this code has seen a lot of testing already,
            The code has been reviewed by a number of people, granted the number of people who can make sense of gpu power management code is limited :-P
            Dave.
            I was just recollecting his previous responses to large merges, like the "What is this crap?!" that he's said before. But perhaps that's just from a testing viewpoint, and not code review. I guess he doesn't really have time to do code reviews of the things he merges.

            Comment


            • #7
              Originally posted by Azpegath View Post
              I was just recollecting his previous responses to large merges, like the "What is this crap?!" that he's said before. But perhaps that's just from a testing viewpoint, and not code review. I guess he doesn't really have time to do code reviews of the things he merges.
              again the bullshit argument about seeing more eyes the code or foss is useless or something like that.

              I cant hear it any more... first of all there are more reasons for foss, when you argue in the way that oss means the same than free software, for some people thats shurly true but not for all, but ok...

              But even that point, yes you get not of every line of code 100 code reviews from people understand exactly what here happens. BUT some people read over it, and if there are some tcp-ip daemon port opening code like if login==NSA and password==NSA or something like that in the changelog, or if user has-interesting data open ssh port or something similar yes somebody would see that.

              And even if you really that good to hide some good bugs that are not obvious and you could use against somebody, still you would most probably not use the radeon module to make such a backdoor because most users dont have radeon gpus. and even most use intel gpu you would most probably use a network-subsystem or something like that to target every linux-user.

              And I think the network-stack is watched over more eyes than the radeon drivers.


              And there is another point there are programms that make automatic code analyses they also need the source and cant check microsoft code as example.

              so yes security most likely is much much higher for opensource stuff in any case even if no men would look over the code except the paid developer from the company...

              Comment


              • #8
                The AMD Radeon HD 8000 "Sea Islands" support for the open-source driver. AMD hasn't yet released their GCN 2.0 hardware, but there's early support within the Linux 3.11 kernel. Patches have also been submitted for libdrm and the RadeonSI Gallium3D driver living in Mesa.
                The age of AMD has officially begun.

                Comment


                • #9
                  Originally posted by Azpegath View Post
                  It's going to be fun to see Linus' response to this =)

                  Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:

                  I wanted to respond to this comment in my last comment.

                  Comment


                  • #10
                    Originally posted by tygrus View Post
                    By the sounds of it .. how do you fit such as big driver with the kernel updates, boot disks and distributions. I would love to see them have a basic core driver that is simple and small to get the computer started and then allows the system to load or swap drivers to enable playing games and advanced features. If it's done right we have the convenience of a small driver that is included everywhere and the user can then load the fancy stuff after the initial boot. Otherwise we are left with big packages and updates even before you can boot.
                    All 3d stuff is in Mesa so in a way this is already the case. In any cases i can almost assure you that what you are loading with Linux is smaller then what you would load with catalyst (not that that automatically equals faster)

                    Comment

                    Working...
                    X