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: <1300965475.12159.32.camel@thor.local>
Date:	Thu, 24 Mar 2011 12:17:55 +0100
From:	Michel Dänzer <michel@...nzer.net>
To:	Dave Airlie <airlied@...il.com>
Cc:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

On Don, 2011-03-24 at 21:06 +1000, Dave Airlie wrote: 
> 2011/3/23 Michel Dänzer <michel@...nzer.net>:
> > On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote:
> >> 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.
> >
> > No, one central point is not to leave two holes between
> > _DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and
> > _DRM_VBLANK_TYPES_MASK .
> 
> Okay I've pushed this to my tree before this discussion got on my
> radar and I'm just catching up now.
> 
> I'll push the following patch to Linus to keep the biggest gap in the
> 32-bit word for future use, then we can fixup the userspace patches.

As we discussed on IRC, I'd personally go further, but this is
definitely an improvement and fixes the worst problems. Thanks Dave.

Reviewed-by: Michel Dänzer <michel@...nzer.net>


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ