Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

files that include userspace headers #6

Open
justincormack opened this issue Oct 14, 2013 · 3 comments
Open

files that include userspace headers #6

justincormack opened this issue Oct 14, 2013 · 3 comments
Labels

Comments

@justincormack
Copy link
Member

x86_64/include/linux/auto_fs.h:#include <sys/ioctl.h>
x86_64/include/linux/coda.h:#include <sys/types.h>
x86_64/include/linux/coda.h:#include <sys/time.h>
x86_64/include/linux/videodev2.h:#include <sys/time.h>
x86_64/include/drm/drm.h:#include <sys/ioccom.h>
x86_64/include/drm/drm.h:#include <sys/types.h>
x86_64/include/linux/netfilter_ipv4/ip_queue.h:#include <net/if.h>
x86_64/include/linux/l2tp.h:#include <netinet/in.h>
@justincormack
Copy link
Member Author

Maybe I am getting this the wrong way round - see also #1 and the problem is the headers that include kernel ones for these. The new (uapi) headers in linux git head now have for linux/input.h:

#ifndef __KERNEL__
#include <sys/time.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <linux/types.h>
#endif

The main issues are

  1. are the headers consistent with each other so they can all be included together, so they all need to include the same headers consistently (which they do not now)
  2. do any of the userspace includes define anything inconsistent with the kernel ABI thus making the ABI incorrect.

Making the kernel headers complete and self contained is great as a definition of the ABI, but makes them harder to use in a program that needs other headers too.

So you either use sys/ioctl.h everywhere and remove linux/ioctl.h from the kernel headers, or you use linux/ioctl.h everywhere and never include sys/ioctl.h - in this case these headers define the same macros (consistently).

The issue of whether userspace and the kernel conflict is somewhat unclear. With glibc I suspect the exercise may well be impossible, like so many things. With Musl, there should be very few places where kernel headers conflict and so the linux/ one needs to be used exclusively.

So I think the thing to do is upgrade to 3.7+ #7 and then attempt to apply fixes to use /sys/ headers where needed (in a branch) and see how that looks in Musl (and glibc).

@rofl0r
Copy link
Member

rofl0r commented Jan 27, 2014

do the current changes to libc-compat.h fix this issue?

@justincormack
Copy link
Member Author

Looks like it should help; I need to write some tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants