linux-kernel - Re: [PATCH] Add virtio gpu driver.

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: <CAKMK7uEK867bF+cdvoA=FyFo-zw7UwK9Bzi2boVFLQ0R4wSh3w@mail.gmail.com>
Date:	Tue, 31 May 2016 08:55:17 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Gerd Hoffmann <kraxel@...hat.com>
Cc:	virtio-dev@...ts.oasis-open.org,
	"Michael S. Tsirkin" <mst@...hat.com>,
	"open list:ABI/API" <linux-api@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>,
	"open list:VIRTIO CORE, NET..." 
	<virtualization@...ts.linux-foundation.org>,
	Dave Airlie <airlied@...hat.com>
Subject: Re: [PATCH] Add virtio gpu driver.

On Tue, May 31, 2016 at 8:29 AM, Gerd Hoffmann <kraxel@...hat.com> wrote:
>>  but it also means that
>> atomic userspace can't use hotspots before we add properties to fbs. And
>> doing that is a bit tricky since drm_framebuffer objects are meant to be
>> invariant - this assumption is deeply in-grained into the code all over
>> the place, everything just compares pointers when semantically it means to
>> compare the entire fb (including backing storage pointer/offsets and
>> everything).
>
> Hmm, the hotspot location for a given cursor image is invariant too, so
> I don't think that would be a big issue.
>
> I'd expect userspace define a bunch of cursors, then switch between them
> (instead of defining a single cursor, then constantly updating it).

Agreed, conceptually it would be a really nice fit to put the hotspot
into the invariant drm_framebuffer. I just meant to say that you need
to add a bit of new uapi to make it happen, since we can't reuse our
existing get/set_prop functions (since those only change props after
the object is created). And we also can't use our existing ioctls to
enumerate properties of an object (since chicken-egg: you want the
list of properties before creating a new framebuffer, so can't use
that framebuffer to enumerate them).

But really not a big concern.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch