On Mon, Apr 20, 2015 at 07:22:49PM +0100, Daniel Stone wrote: > Hi, > This is the spritual successor to the modes-as-blob-properties patchset. > > There are some fairly drastic differences though, namely: > - the referenced object in this case is the blob property - being just > a dumb chunk of data - rather than attempting to refcount modes; > meaning that ... > - userspace doesn't see blob mode IDs from the connector list, only > from the current mode, so it really needs to create the mdoes again > from the drm_mode_modeinfo it gets > - the mode-constness series has been split out and will be sent > separately > > Actually exposing the mode property does largely seem to work, but > need to fix i915 to not copy CRTC states by value before it does. > > This series still retains the concept of a type within the create blob > ioctl, on the grounds that otherwise we could allow userspace to create > unbounded allocations in the kernel with no attribution. Other than > matching size, the type has no meaning per se. Yeah I'm a bit late, but not sure whether trying to restrict the size is all that useful really. Userspace can still just create a bazillion of them and starve the kernel of memory. And as long as we use kmalloc there'll be a natural limit to how big a blob can be. I'm bringing this up since if we go with encoding size limits we'll need to add a new type of blob for each use, and with gamma tables, csc matrices and other stuff there will be lots of them. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
