On 17 November 2015 at 07:22, Michel Dänzer <michel@xxxxxxxxxxx> wrote: > On 14.11.2015 07:06, Emil Velikov wrote: >> On 13 November 2015 at 21:36, Gabriel Laskar <gabriel@xxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
