Is there is a common practice for userspace programs to include ioctl codes used in a kernel module.
mydev.h:
#ifndef MYDEV_H
#define MYDEV_H
#define <linux/ioctl.h>
#define MYDEV_IOC_MAGIC 'C'
#define MYDEV_IOC_FOO _IO(MYDEV_IOC_MAGIC, 0)
#define MYDEV_IOC_BAR _IOW(MYDEV_IOC_MAGIC, 1, int)
#endif
I typically put my ioctl codes in a header which I include in my kernel module code. I considered just including this header in my userspace applications, but I realized that the linux/ioctl.h file path may not exist on most systems (e.g. systems with no exported kernel headers).
The solution seems to be to change the include line to: #include <sys/ioctl.h>; but then I couldn't use this header for my kernel module.
Is there a better solution to this problem, or is it common to have two separate but nearly identical header files?
You could leverage the _KERNEL_ macro.
#ifdef __KERNEL__
#include <linux/ioctl.h>
#else
#include <sys/ioctl.h>
#endif
You may have to abstract the actual ioctl values too, but you get the idea.
Related
I'm using a header only library called Nuklear. It's a header only library. I'm having trouble when using multiple includes from different files. It returns a multiple definition example:
...
obj/main.o:main.c:(.text+0x4a52b): multiple definition of `nk_sdl_font_stash_begin'
obj/components.o:components.c:(.text+0x4a56f): first defined here
obj/main.o:main.c:(.text+0x4a563): multiple definition of `nk_sdl_font_stash_end'
obj/components.o:components.c:(.text+0x4a5a7): first defined here
obj/main.o:main.c:(.text+0x4a5f4): multiple definition of `nk_sdl_handle_event'
obj/components.o:components.c:(.text+0x4a638): first defined here
obj/main.o:main.c:(.text+0x4ac9f): multiple definition of `nk_sdl_shutdown'
obj/components.o:components.c:(.text+0x4ace3): first defined here
I'm attempting to include the library into 2 files.
main.c
#define SDL_MAIN_HANDLED
#include <GL/glew.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_opengl.h>
#define NK_INCLUDE_FIXED_TYPES
#define NK_INCLUDE_STANDARD_IO
#define NK_INCLUDE_STANDARD_VARARGS
#define NK_INCLUDE_DEFAULT_ALLOCATOR
#define NK_INCLUDE_VERTEX_BUFFER_OUTPUT
#define NK_INCLUDE_FONT_BAKING
#define NK_INCLUDE_DEFAULT_FONT
#define NK_IMPLEMENTATION
#define NK_SDL_GL3_IMPLEMENTATION
#include "nuklear.h"
#include "nuklear_sdl_gl3.h"
#include "components.h"
...
components.c
#define SDL_MAIN_HANDLED
#include <GL/glew.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_opengl.h>
#define NK_INCLUDE_FIXED_TYPES
#define NK_INCLUDE_STANDARD_IO
#define NK_INCLUDE_STANDARD_VARARGS
#define NK_INCLUDE_DEFAULT_ALLOCATOR
#define NK_INCLUDE_VERTEX_BUFFER_OUTPUT
#define NK_INCLUDE_FONT_BAKING
#define NK_INCLUDE_DEFAULT_FONT
#define NK_IMPLEMENTATION
#define NK_SDL_GL3_IMPLEMENTATION
#include "nuklear.h"
#include "nuklear_sdl_gl3.h"
The Nuklear library already includes header guards so I'm not sure why this error is happening. Any advice?
From the README at GitHub:
This library is self contained in one single header file and can be used either in header only mode or in implementation mode. The header only mode is used by default when included and allows including this header in other headers and does not contain the actual implementation.
The implementation mode requires to define the preprocessor macro NK_IMPLEMENTATION in one .c/.cpp file before #includeing this file, e.g.:
#define NK_IMPLEMENTATION
#include "nuklear.h"
So, only one of main.c and components.c should include the #define NK_IMPLEMENTATION — yet you define it in both.
Fix
Remove #define NK_IMPLEMENTATION from components.c.
Do not include any other Nuklear header than nuklear.h — the instructions don't tell you to do that (at least, not on the surface; maybe there's something elsewhere that says so, but …).
The documentation also notes:
IMPORTANT: Every time you include "nuklear.h" you have to define the same optional flags. This is very important not doing it either leads to compiler errors or even worse stack corruptions.
It would probably be worth having your own header — use_nuklear.h for example, though I'm sure you'll think of a better name — that contains the correct set of NK_* options (all except NK_IMPLEMENTATION). Then #include "use_nuklear.h" in your source files. That way, if (when) you change options, you have only one place to change — and the rebuilds will be consistent.
You should only #define NK_SDL_GL3_IMPLEMENTATION in one of your .c source files before you #include "nuklear_sdl_gl3.h".
The nuklear_sdl_gl3.h file contains all the function definitions, as well as function declarations, and you only want the definitions in one place or, as you've found, your linker will complain.
nuklear_sdl_gl3.h contains data and functions. It is just very badly written. All definitions should be in the .c files and only declaration, type definitions, extern variables declarations and static inline functions should be in the header file.
You cant include this file more than once in the whole project. The guards do not work here as it is included in different compilations units.
I'm writing the header of a kernel module. The header is known to the module, but also used by callers in user space. This is a problem, because some types used should be included from different files depending on whether the header is currently in user or kernel space (or so this question makes me think).
I don't want to maintain two separate header files, so I've been thinking of a solution like this:
#ifndef IN_KERNEL
#include <stdint.h>
#else
#include <linux/types.h>
With IN_KERNEL being defined somewhere in my kernel code. Is there a preprocessor constant that already does this?
From reading this, it seems that an existing constant used for this purpose is __KERNEL__.
#ifndef __KERNEL__
#include <stdint.h>
#else
#include <linux/types.h>
#endif
I'd line to use pthread_setname_np function if it's available. Code from the manpage:
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <pthread.h>
int pthread_setname_np(pthread_t thread, const char *name);
int pthread_getname_np(pthread_t thread,
char *name, size_t len);
Is it safe to just do like that (no includes, no defines):
#ifdef _GNU_SOURCE
pthread_setname_np(pthread_self(), "mythread");
#endif
Includes are not needed because the C++ #include <thread> that I use seems to pull pthreads. The _GNU_SOURCE is always enabled in libstdc++, and if it gets disabled - the code will still compile.
Am I missing something?
Is it safe to just do like that (no includes, no defines):
Yes. It's safe as long as you include <pthread.h> which provides the prototype for pthread_setname_np.
Includes are not needed because the C++ #include that I use seems to pull pthreads.
libc++ uses pthreads library underneath. So, it works with pthread.h. But that doesn't mean pthread.h isn't needed if you include <thread>. What if libc++ changes the underlying mechanism to implement threads? So, it's not safe to by pass pthread.h just because it happens to be available by other means.
I want to write a portable way to get the free disk space. On Windows, I use GetDiskFreeSpaceEx, and on Linux, the header <sys/statvfs.h> contains the function statvfs64() I can use.
My question is, on which systems I can assume that this header exists. Is there a macro I can check? Something like
#ifdef _MSC_VER
#include <windows.h>
#else
#ifdef STATVFS_IS_AVAILABLE
#include <sys/statvfs.h>
#endif
#endif
Generally, you would use autotools for stuff like that. autoconf creates a config.h header which defines a HAVE_STATVFS or so macro if you define a suitable configuration test.
However, due to the otherwise huge availability of <sys/statvfs.h>, you can also less portably simply test for _MSC_VER, as you just did.
I would like to use
#include <time.h>
clock_gettime(CLOCK_TAI, &...);
but unfortunately CLOCK_TAI is not defined in stock time.h header (in openSUSE 13.2 at least). It is however defined in linux/time.h and actually supported by the operating system. But if I include the latter header, it provokes a bunch of declaration conflicts — versus both time.h and bits/types.h. Including only the linux/time.h does not help, as time.h and/or bits/types.h will be implicitly included by common headers, like unistd.h or stdlib.h, anyway.
So I tried to resolve conflicts manually. Particularly, the first compiler error message was about timespec redeclaration, so I wrote in my code:
#include <time.h>
#if defined(__timespec_defined) && !defined(_STRUCT_TIMESPEC)
#define _STRUCT_TIMESPEC
#endif
#include <linux/time.h>
It worked, but not without yet another conflict with itimerspec redeclaration, which is declared unconditionally in both headers and is not concluded with definitions of any include guards. So I decided to ban implicit time.h inclusion altogether:
#include <linux/time.h>
#ifndef _TIME_H
#define _TIME_H
#endif
This continued with compiler complaining about timeval redeclaration. So I banned implicit bits/types.h inclusion as well:
#include <linux/time.h>
#ifndef _TIME_H
#define _TIME_H
#endif
#ifndef _BITS_TYPES_H
#define _BITS_TYPES_H
#endif
Alright, but this removes important basic declarations as well, upon which common types like size_t are based. So I tried to go in the opposite direction and disable linux/types.h inclusion:
#ifndef _LINUX_TYPES_H
#define _LINUX_TYPES_H
#endif
#include <linux/time.h>
#ifndef _TIME_H
#define _TIME_H
#endif
As you can guess, it resulted in system-specific types like __kernel_time_t being missing, which leaded to inability to declare timespec and so on.
Thus I am wondering: is it at all possible to use linux/… headers in combination with stdlib.h and other commonly included files? Are there other ways to access system-specific CLOCK_TAI value?