Re: [git pull] drm fixes

[Dave Airlie <airlied@gmail.com>]

2011/3/25 Michel Dänzer <michel@daenzer.net>:
> On Fre, 2011-03-25 at 17:21 +1000, Dave Airlie wrote:
>> On Fri, Mar 25, 2011 at 10:17 AM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>> > On Thu, Mar 24, 2011 at 5:07 PM, Dave Airlie <airlied@gmail.com> wrote:
>> >>
>> >> Like seriously you really think VFS locking rework wasn't under
>> >> development or discussion when you merged it? I'm sure Al would have
>> >> something to say about it considering the number of times he cursed in
>> >> irc about that code after you merged it.
>> >
>> > Umm. That code was basically over a year old by the time it was merged.
>> >
>> > How old was the code we're talking about now? Seriously?
>>
>> It was 30 lines of clean code, that really was fine to be merged in
>> its first form it was merely a future maintaince issue to clean up the
>> interface before it was released as stable.
>
> From my POV the real failure here was that the change made it to *any*
> tree while there were outstanding review issues from when it was
> initially discussed a few weeks earlier. Then when the change was
> submitted — more or less unchanged — I was on my birthday weekend
> enjoying some time away from computers, and when I had caught up with
> things, it was already in drm-next.

Thats the problem really I read all the discussion and there wasn't
much that seemed bad, I think the problem with your suggestions was
there was a lot of latitude to disagree with them and I read the
comments and disagreed with them as well, and it fixed the problem so
I decided it should be pushed or we'd end up waiting another 6 months
to fix it for the people who it actually affects. This isn't the
message that I'd like to send to people who get off their arses and
fix our fuckups.

>
>
>> In this case, if you had a >2 monitor setup connected to an evergreen
>> card, and you tried to do 3D on the 3rd monitor it would just hang the
>> app in a loop forever, the fix needs 3 pieces, one in the kernel, and
>> two userspace fixes.
>
> Actually, the hangs could be fixed in the X driver alone, but the author
> seems uninterested in contemplating that. Maybe because he seems to
> think it's easier to get the kernel fix to users, but I'm with you on
> that it's quite clearly the opposite.

I can't see how you can actually fix the hangs in userspace, you can
hack around the hangs so the user just gets a less useful behaviour
and make maintaining the userspace hack forever, or you can fix the
insufficient kernel interface and get it out quick. I'm not really
into the whole put a userspace hack in and maintain it for years thing
either, and I'd rather nobody else ever decided it was a good idea.

Dave.