[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v2] Added uapi directory into linux-header

From: David Howells
Subject: Re: [Qemu-ppc] [PATCH v2] Added uapi directory into linux-header
Date: Tue, 18 Dec 2012 14:10:20 +0000

Alexander Graf <address@hidden> wrote:

> But looking through this whole thing, it seems like the root cause is
> actually different. We don't want any uapi directories exposed to user
> space. So let's go back a step:
> Why do we need the uapi include dir? Because some header is using it.
> linux-headers/asm-powerpc/kvm_para.h:
>     #include <uapi/asm/epapr_hcalls.h>
> This is the root cause of the problem. We must never manually include any
> uapi header paths. We only ever include their normal asm-counterparts which
> then may include uapi (in kernel) or actually are uapi (in user
> space). David, please correct me if I'm wrong.

I think you're correct, if I understand what you're saying.

Within the kernel sources, the userspace facing headers are in uapi/
directories whilst the stuff userspace shouldn't see is outside of that.

uapi/ headers should _not_ #include headers with uapi/ prefixes; rather they
should rely on the -I flags to pull in the UAPI header if the KAPI header of
the same name does not exist.

However, KAPI headers that shadow UAPI headers (linux/fs.h for example) _must_
manually #include the UAPI header with the uapi/ prefix as there's no other
way to reach it.  I originally used #include_next for this, but some people
refused to countenance it because it's a gcc-ism, but no matter.

After doing make headers_install in the kernel, you should find the contents
of the appropriate uapi/ directories installed in the target directory without
any uapi/ directories present.  Further, the _UAPI prefixes on the guards are
removed if present.  There should be no #includes with "uapi/" in their


reply via email to

[Prev in Thread] Current Thread [Next in Thread]