All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Emil Velikov <emil.l.velikov@gmail.com>,
	Gabriel Laskar <gabriel@lse.epita.fr>
Cc: Mikko Rapeli <mikko.rapeli@iki.fi>,
	DRI devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/9] uapi: drm: fixes for userspace compilation
Date: Wed, 18 Nov 2015 12:12:23 +0900	[thread overview]
Message-ID: <564BEC97.5070309@daenzer.net> (raw)
In-Reply-To: <CACvgo50jCHD1CX-0=J8eqk2=iSe7=ndKfHTqT2itKQq--x7ryg@mail.gmail.com>

On 18.11.2015 06:22, Emil Velikov wrote:
> On 17 November 2015 at 19:13, Gabriel Laskar <gabriel@lse.epita.fr> wrote:
>> On Tue, 17 Nov 2015 11:08:12 +0000
>> Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> 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.
>>
>> We are not suggesting doing s|drm/drm.h|drm.h| but by replacing
>>
>> #include <drm/drm.h>
>>
>> by
>>
>> #include "drm.h"
>>
>> The header will be picked-up correclty in kernel, and in userland.
>>
> Missed out completely on the <> vs "" side. Imho using the latter the
> kernel will be ok, although for userspace that's not a good idea. What
> will happen if there is a drm.h next to the .c files (I know bad
> programmer) ?

Nothing, at least not with gcc:
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

 GCC looks for headers requested with #include "file" first in the
 directory containing the current file, then in the directories as
 specified by -iquote options, then in the same places it would have
 looked for a header requested with angle brackets. For example, if
 /usr/include/sys/stat.h contains #include "types.h", GCC looks for
 types.h first in /usr/include/sys, then in its usual search path.

So #include "drm.h" always picks up drm.h from the same directory where
*_drm.h is.


A for me being confused:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/uapi/drm/amdgpu_drm.h?id=b3fcf36aeef3aeb890d9413c2066048ec7fda7e5

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/uapi/drm/radeon_drm.h?id=e13af53e7d5a8cea8992d9b61fac69bd0ed8d845


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-11-18  3:12 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 18:14 [PATCH 0/9] uapi: drm: fixes for userspace compilation Gabriel Laskar
2015-11-12 18:14 ` [PATCH 1/9] include/uapi/drm/armada_drm.h: use __u{32,64} types instead of uint{32,64}_t Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 2/9] include/uapi/drm/virtgpu_drm.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 3/9] include/uapi/drm/qxl_drm.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 4/9] include/uapi/drm/nouveau_drm.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 5/9] include/uapi/drm/amdgpu_drm.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 6/9] include/uapi/drm/armada_drm.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 7/9] include/uapi/drm/drm_mode.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 8/9] include/uapi/drm/vmwgfx_drm.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 18:14 ` [PATCH 9/9] include/uapi/drm/omap_drm.h: " Gabriel Laskar
2015-11-12 18:14   ` Gabriel Laskar
2015-11-12 19:34 ` [PATCH 0/9] uapi: drm: fixes for userspace compilation Emil Velikov
2015-11-13 19:24   ` Gabriel Laskar
2015-11-13 19:31     ` Gabriel Laskar
2015-11-13 20:38       ` Emil Velikov
2015-11-13 21:36         ` Gabriel Laskar
2015-11-13 22:06           ` Emil Velikov
2015-11-17  7:22             ` Michel Dänzer
2015-11-17 11:08               ` Emil Velikov
2015-11-17 19:13                 ` Gabriel Laskar
2015-11-17 21:22                   ` Emil Velikov
2015-11-18  3:12                     ` Michel Dänzer [this message]
2015-11-18 12:54                       ` Emil Velikov
2015-11-17 20:13                 ` Dave Airlie
2015-11-17 22:00                   ` Emil Velikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=564BEC97.5070309@daenzer.net \
    --to=michel@daenzer.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=gabriel@lse.epita.fr \
    --cc=mikko.rapeli@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.