[Mesa-dev] [PATCH 0/2] anv/i965: drop libdrm dependency completely

[Emil Velikov]

On 27 April 2017 at 16:20, Eric Anholt <eric at anholt.net> wrote:
> Emil Velikov <emil.l.velikov at gmail.com> writes:
>
>> On 25 April 2017 at 23:56, Lionel Landwerlin
>> <lionel.g.landwerlin at intel.com> wrote:
>>> Hi,
>>>
>>> While working with changes that span from kernel to user space, I've
>>> been wondering whether we need to depend on libdrm at all for the anv
>>> & i965 drivers. Indeed with Ken's recent changes, we only depend on
>>> libdrm for its kernel header files which we could just embed
>>> ourselves.
>>>
>>> I've only included the minimal set of header files we need from the
>>> kernel for anv & i965. Maybe other drivers would be interested and
>>> maybe we should put all the kernel drm uapi headers into include?
>>>
>> AFAICT the goal behind the libdrm_intel fold was to allow rapid and
>> seamless rework of the interface.
>> With a potential goal to make it a shared one, as it gets stabilised.
>>
>> Currently ANV uses more than just the UAPI headers. But if we ignore
>> that, coping them is a bad idea.
>>
>> Why - adds a, yet another, copy and making synchronisation more
>> annoying. First example - you blindly copied the files rather than
>> using `make headers_install' first ;-)
>> Not to mention that it makes the chicken and egg problem* even more
>> confusing and error prone.
>>
>> Emil
>> *  Which patches land first - kernel or userspace
>
> I don't see how it does that at all.  It simplifies the process: Now you
> send out your proposed new userspace to one repo, instead of two.
>
Funny that you should say that. On my count there's 4 instances of the
VC4 headers - one in kernel and 3 in different userspace components.
With each one subtly different from the rest.

Now consider what will happen if you throw a dozen+ developers.

> And, after the first commit, it'll be obvious when you screw up using
> make headers_install because there will be surprising diff.

People rarely look at these. Bu even ignoring that for a moment:
Developers simply don't reference (hint hint [1]) the kernel commit
thus it's impossible to verify the patch.

-Emil
[1] See your libdrm commits 2212a6465d1597fbc4d4ee0ea5ff87816bfa336e
and 2212a6465d1597fbc4d4ee0ea5ff87816bfa336e