On 2 October 2014 20:40, Bloomfield, Jon <jon.bloomfield@xxxxxxxxx> wrote: > On Fri, Sep 19, 2014 Daniel Vetter wrote: >> I still consider pinning stuff behind the kernels back too evil. So if people >> want that I'd like to see the use-case and why we can't do this differently. >> >> And I've never approved of the pin ioctl but really loudly complained about >> each occasion I've spotted, so I think the internal users just have to keep the >> pieces for a bit longer. >> -Daniel > > Daniel. All that's being asked for is a re-instatement of the old mechanism until > a better solution can be designed and implemented. > > It may well be evil, but the mechanism was there, and was the only known > way to handle the OA buffer, so why wouldn't someone use it ? You've broken > userspace before you provided any alternative solution. > > Please, let's revert this while a more elegant solution is designed, implemented, > reviewed, re-implemented, reviewed again, and maybe one day merged. > > Remember that it will take a while to filter down to people even after you merge > any new solution to nightly, or even drm-next. If we have to wait for the new > design, it's not likely to reach us until next year. > > Can't we just agree that we're evil, but turn a blind eye while we're coaxed slowly > back towards the light ? I thought we had an agreement that no features that were specific to the non-open source userspace drivers would be merged to the kernel, due to security and maintenance concerns, i.e. exactly this concern, we now have to maintain an interface that we can't regression test in public. Maybe next time who ever made the decision to force merge code will learn why its a bad idea. Personally I don't think this interface should be put back in, unless Mesa/Beigenet/libva uses it, does it even have igt tests? Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
