Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: DRM Patches For Linux 2.6.27 Kernel

  1. #11

    Default

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

  2. #12
    Join Date
    Jul 2007
    Posts
    405

    Default

    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.

  3. #13
    Join Date
    Mar 2008
    Posts
    97

    Default

    Quote Originally Posted by Michael View Post
    Linus Torvalds to David Airlie:
    Epic fail.

  4. #14
    Join Date
    Mar 2008
    Posts
    97

    Default

    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.

  5. #15
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,577

    Default

    Quote 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; 08-24-2008 at 05:27 PM.

  6. #16
    Join Date
    Apr 2007
    Location
    Bulgaria
    Posts
    269

    Default

    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; 08-24-2008 at 05:22 PM.

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,577

    Default

    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; 08-24-2008 at 05:55 PM.

  8. #18
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,587

    Default

    Quote 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.

  9. #19

    Default

    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.

  10. #20
    Join Date
    May 2008
    Location
    Parish, NY
    Posts
    159

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •