Announcement

Collapse
No announcement yet.

DRM Patches For Linux 2.6.27 Kernel

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

  • #11
    Yeah. I'm supporting Linus on this. David has done late merges like this not a few times.

    Comment


    • #12
      Linus really needs to be nicer to the poor DRM devs. Sure, I can understand why he rejected the patch, but he could have been more polite about it.

      Comment


      • #13
        Originally posted by Michael View Post
        Linus Torvalds to David Airlie:
        Epic fail.

        Comment


        • #14
          Linus really needs to be nicer to the poor DRM devs. Sure, I can understand why he rejected the patch, but he could have been more polite about it.
          Sometimes polite doesn't have enough emphasis to make someone understand.

          Comment


          • #15
            Originally posted by Louise View Post
            So that was what his huge patch was about =)

            Does this mean, that AMD will spilt future specifications up in a DRM spec, 2D, 3D, and ISA spec? Or can it not be divided like that?
            The natural split from a developer's POV would be something like :

            - Modesetting (basic memory management, display controllers)

            - Acceleration (everything else)

            This is pretty much what we ended up doing for 5xx and 6xx, although :

            - the modesetting docs (released in 07) were missing some memory controller bits which we supplied separately to the devs

            - 6xx acceleration was split in two parts in order to take advantage of the R600 shader ISA doc which had been prepared by our Stream Computing folks

            Going forward we will probably continue to "play it by ear" a bit -- for example the 7xx is close enough to 6xx that we will probably just create a single "delta document" covering all of the differences between 6xx and 7xx rather than splitting into modesetting vs isa vs acceleration.

            We looked at organizing the documentation around the driver components, however in the current X/DRI architecture there is a fair amount of duplication between the X driver and the DRM driver. That duplication will continue (and maybe even grow for a while) but hopefully will disappear once kernel modesetting becomes the norm. Once that happens the X/DRI graphics stack will be more like the rest of Linux, with kernel drivers doing all the register-banging and usermode drivers passing command buffers down through DRM to implement acceleration APIs.
            Last edited by bridgman; 24 August 2008, 04:27 PM.
            Test signature

            Comment


            • #16
              Yeah, but he is kind of accusing people that they don't know what a "merge window" is, instead of tutoring them in a true mentor style
              Last edited by sundown; 24 August 2008, 04:22 PM.

              Comment


              • #17
                I think some of this is just about making the rules more clear. There have been previous comments saying "only bug fixes after the merge window" but all of Dave's changes *were* bugfixes. Linus' email makes it sound as if the real expectation is "only bug fixes for *regressions* after the merge window", which is a big difference and which is probably *too* strict for effective development.

                It may just be that Dave's changes came in *after* rc4 so Linus is enforcing the "regressions only" rule because the next milestone is hopefully "final" and there is no room for further fixes. If so, that means the rule is really "only bugfixes for regressions after rc4", which would be totally reasonable.
                Last edited by bridgman; 24 August 2008, 04:55 PM.
                Test signature

                Comment


                • #18
                  Originally posted by sundown View Post
                  Yeah, but he is kind of accusing people that they don't know what a "merge window" is, instead of tutoring them in a true mentor style

                  They obviously DON'T understand what a "merge window" is. I have to stand by Linus on this one. If people don't follow the deadlines your QC is at risk.

                  Comment


                  • #19
                    I read the thread and the response to Linus by Mr. Airlie:

                    Your reply now serves as place to point people at when they ask why Red Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine with that.

                    Dave.
                    I think... Mr. Airlie is wrong about his statement. The fact is, the patches he's submitting are available. Anybody can take those patches and merge them into their own kernels.

                    There should not be anybody then asking why Red Hat / Fedora ships with code that they can't ship, unless the code is proprietary. If the changes to the code are that dramatic and useful, vendors will simply include the code themselves, rather than waiting on an official kernel version.

                    Then if the vendor won't include the code, there's nothing to stop the end user themselves from including the code.

                    So, I'm not sure what Mr. Airlie is fine with. On the surface, it sounds like he's fine with proprietary code and keeping it locked away... I just can't imagine that being his intent.

                    My guess is that Mr. Airlie didn't actually think about what he wrote back, instead trying to be cute and make Linus look bad while promoting his own product.

                    Comment


                    • #20
                      Maybe I'm giving him the benefit of the doubt, but I'm siding with Linus.

                      Why the qualification? Because if he asked nicely we wouldn't here about it. At all. Not just his response, but the whole thing. He probably did. Maybe not to this particular dev, maybe not on this particular issue, maybe not for this particular kernel. But I can guarantee that he's asked nicely in a similar situation before.

                      Sometimes you gotta lay down the law.

                      Comment

                      Working...
                      X