[Mesa-dev] [PATCH 07/10] egl/android: Make drm_gralloc headers optional

[Tomasz Figa]

On Sat, Jul 16, 2016 at 11:17 PM, Rob Herring <robh at kernel.org> wrote:
> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa <tfiga at 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