linux-kernel - Re: [git pull] drm fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.GSO.4.62.1103230633160.12612@umail>
Date:	Wed, 23 Mar 2011 06:40:32 -0500 (CDT)
From:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>
To:	Dave Airlie <airlied@...il.com>
cc:	Michel Dänzer <michel@...nzer.net>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes


On Wed, 23 Mar 2011, Dave Airlie wrote:

> 2011/3/23 Michel Dänzer <michel@...nzer.net>:
>> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
>>> 2011/3/23 Michel Dänzer <michel@...nzer.net>:
>>>> On Mit, 2011-03-23 at 04:18 +0000, Dave Airlie wrote:
>>>>>
>>>>> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
>>>>> in vblank.
>>>>
>>>> [...]
>>>>
>>>>> Ilija Hadzic (1):
>>>>>       drm/kernel: vblank wait on crtc > 1
>>>>
>>>> This patch was still being debated yesterday, are you deliberately
>>>> pushing it regardless? Once it hits mainline, it'll be pretty much set
>>>> in stone.
>>>
>>> From what I can see it was the userspace patches being debated, this
>>> one seemed fine and the interface looked okay to me.
>>
>> The author ignored my suggestions to make the patch smaller and simpler,
>> more maintainable and more future-proof all at once.
>
> It was already small and I'm not sure merging the flags made it more
> maintainable. Its always
> being a slightly painful ioctl, and hopefully any future changes add a
> new ioctl esp if we want 64-bit values.
>
> The only comment I really thought was necessary was changing the CAP
> name, but since that isn't
> part of the ABI (just the number) we can quickly fix it with a follow-up.
>
> Dave.

All of the issues debated yesterday, except one, boil down to renaming a 
handful on #defines without changing the values nor interface nor behavior 
of the kernel. For those that I agreed, I'll follow up with a small patch 
shortly.

-- Ilija