On Sat, 1 Dec 2012 01:03:39 +0100, Daniel Vetter <daniel at ffwll.ch> wrote: > On Sat, Dec 1, 2012 at 12:46 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote: > > On Fri, 30 Nov 2012 23:33:43 +0100, Daniel Vetter <daniel at ffwll.ch> wrote: > >> On Thu, Nov 15, 2012 at 11:32:25AM +0000, Chris Wilson wrote: > >> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> > >> > >> Tbh I don't see any reason for handling pwrite/pread support for stolen > >> mem backed objects. I'll leave these two patches here (plus the prep one > >> to differentiate between stolen and dma_bufs) for now until a user pops > > > > The problem is that constitutes a change in ABI, so I was trying to make > > sure stolen buffer objects were first class from day one. The only > > saving grace is that userspace can only access the stolen object for > > fbcon, but it is still available... > > Hm, I've forgotten that userspace can get at the fbcon. Does it really > do that? The problem I see here is untested code and no sane way to > test it. Hint: the bogus obj->gtt_offset == 0 check was found experimentally. :) No one pwrites/preads to the fbcon, today. If it makes you feel any better, I would like to be able to create objects preferrentially from stolen (e.g. scanouts) and you could build a test interface on top. -Chris -- Chris Wilson, Intel Open Source Technology Centre
