On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote: > I would like to get at least some of the driver upstream. I'd hate > for it to have to live completely out of tree. I can think of a > couple possibilities. > > 1) the best would be, if there was some way for the drm driver to know > the upper/lower bounds of the carveout, then it could bounds-check > against this. And then in worst case, userspace can just screw up > other "graphics" buffers The bounds check does what? Check that the buffer object's physical address is within another driver's range? Fine, but all that it's doing is preventing it being associated with a buffer object which can _only_ be used for _read_ access by the LCD controller. There is no write access to the GEM objects by anything that this DRM driver talks to. So all it'll do is prevent you passing rogue addresses to the LCD controller for scanout. And how do we get that information into the driver from other random drivers? Hack in random inter-driver specific APIs to do it? Come up with yet another different way to try and identify whether a particular resource is a block of reserved memory for this driver's usage as a linear region or one of the others? How. Really, please think about the problem. The benefit vs the complexity involved really isn't worth it. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
