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/inclu...
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/inclu...