On 17 November 2015 at 07:22, Michel Dänzer michel@daenzer.net wrote:
On 14.11.2015 07:06, Emil Velikov wrote:
On 13 November 2015 at 21:36, Gabriel Laskar gabriel@lse.epita.fr wrote:
There is still some issues on the headers, like the inclusion of drm.h.
AFAIK, we should include "drm.h", in order to minimize the changes between linux/libdrm when importing, as the folders are not always the same (on Archlinux for example, drm.h is installed in /usr/include/libdrm/drm.h). This is not always the case in some of the headers:
I'm afraid we cannot do this. Things should just work without the extra include directive (from your earlier example). We can easily fix this and other issues in an automated way during import.
[...]
I can send patches for them too, I just need to know if this is useful, and not just nitpicking for you.
Everything but the s|drm/drm.h|drm.h| suggestion is pretty valid imho.
What's the problem with changing
#include <drm/drm.h>
to
#include "drm.h"
in include/uapi/drm/*_drm.h? I recently made that change in radeon_drm.h and amdgpu_drm.h for the reason Gabriel mentioned above (in particular amdgpu_drm.h is now basically identical between the kernel and libdrm trees), and I haven't noticed any problems because of that.
I believe you're getting confused Michel. You did such change in libdrm not the kernel... unless these changes haven't hit -next yet ?
Let me elaborate on the whole thing:
The kernel UAPI headers: - Used by the kernel modules and userspace(?) - Installed in /usr/include/drm - Many distributions do _not_ ship them - Broken for years (mostly fixed with Mikko's earlier patches) - For the above two reasons - most (all?) userspace uses the libdrm ones.
The libdrm headers: - Mostly preprocessed version of the above, used solely by userspace - Installed in /usr/include/libdrm - All distros ship them - Desperately out of sync wrt the above
With the above said: - I was thinking about hiding the UAPI ones, although Dave suggested against it. - Doing s|drm/drm.h|drm.h| will break compilation: + for the kernel - as we don't add the foo/drm/ to the include directive, + for any hacked up userspace - very unlikely that they have the include, considering that things work without it. - Differences wrt libdrm userspace - all of which can be handled with simple sed + __KERNEL__ never defined so we can just ignore it + __user + drm/drm.h + others ?
Fwiw I still believe that the best solution is to "hide" the UAPI headers, esp since they've been busted for a while. Then we can drop the "drm/" and fix any in-kernel breakage. That said we will need to convince Dave ;-)
Alternatively I suggest that we carry on with my earlier suggestion. That is, unless someone comes with a better plan which doesn't involve ignoring the problem :-P
Cheers, Emil