On Sat, Jul 16, 2016 at 11:17 PM, Rob Herring <r...@kernel.org> wrote: > On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa <tf...@chromium.org> wrote: >> We can support render nodes alone without any private headers, so let's >> make support for control nodes depend on presence of private drm_gralloc >> headers. > > This is a complicated change for what amounts to just needing the > flink name out of the gralloc handle. You don't have the dependency > for prime fds because I assumed it is the first fd in the gralloc > handle (as I was trying to avoid the header dependency). We could do > the same for flink names. > > Whether we want to make support from control nodes ifdef'ed should be > its own option not implied from having headers or not.
Except that flink name is just an integer and it doesn't even have to be present in the handle, so the assumption is much less likely to hold. Prime FD belongs to a separate class and it's very unlikely that there is another file descriptor there, except maybe other Prime FDs when the buffer consist of multiple planes. We don't have flink names in our handles. I was trying to make the change in a manner that doesn't break anything for existing users, while letting new users with gralloc that doesn't provide any custom interface (doesn't even provide access to the handle struct, which should be opaque as the name suggests). Also flink names are not the only custom API that requires those headers. There is also the GET_DRM_FD perform call, which we don't support, because it generally isn't a good idea (gralloc can be stepping over Mesa's feet, because, for example, GEM handles are not reference counted...). Possibly just the macro should be split into two, one GRALLOC_USES_FLINK_NAMES and GRALLOC_HAS_PERFORM_GET_DRM_FD. However, to be honest, I'd be for dropping support for both features and making the gralloc you use saner. Flink names pose a security risk and I don't think there is any reason why we should continue using them, while GET_DRM_FD, even if potentially not unsafe, has its own set of problems. Best regards, Tomasz _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev