[PATCH v4 05/79] exynos_drm.h: use __u64 from linux/types.h

[PATCH v4 05/79] exynos_drm.h: use __u64 from linux/types.h

[Mikko Rapeli]

Fixes userspace compilation error:

drm/exynos_drm.h:30:2: error: unknown type name ?uint64_t?

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/exynos_drm.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index 5575ed1..cf431b7 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -27,7 +27,7 @@
  *	- this handle will be set by gem module of kernel side.
  */
 struct drm_exynos_gem_create {
-	uint64_t size;
+	__u64 size;
 	unsigned int flags;
 	unsigned int handle;
 };
@@ -44,7 +44,7 @@ struct drm_exynos_gem_create {
 struct drm_exynos_gem_info {
 	unsigned int handle;
 	unsigned int flags;
-	uint64_t size;
+	__u64 size;
 };
 
 /**
@@ -58,7 +58,7 @@ struct drm_exynos_gem_info {
 struct drm_exynos_vidi_connection {
 	unsigned int connection;
 	unsigned int extensions;
-	uint64_t edid;
+	__u64 edid;
 };
 
 /* memory type definitions. */
-- 
2.5.0

[PATCH v4 05/79] exynos_drm.h: use __u64 from linux/types.h

[Gustavo Padovan]

2015-10-15 Mikko Rapeli <mikko.rapeli@iki.fi>:

> Fixes userspace compilation error:
> 
> drm/exynos_drm.h:30:2: error: unknown type name ?uint64_t?
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> ---
>  include/uapi/drm/exynos_drm.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

	Gustavo

[PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

[Mikko Rapeli]

xen/interface/xen.h is not exported from kernel headers so remove the
dependency and provide needed defines for domid_t and xen_pfn_t if they
are not already defined by some other e.g. Xen specific headers.

Suggested by Andrew Cooper <andrew.cooper3@citrix.com> on lkml message
<5569F9C9.8000607@citrix.com>.

The ifdef for ARM is ugly but did not find better solutions for it.

Fixes userspace compilation error:

xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 arch/arm/include/asm/xen/interface.h |  2 +-
 include/uapi/xen/privcmd.h           | 14 +++++++++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 5006600..68a9d99 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -36,7 +36,7 @@
  * fine since it simply wouldn't be able to create any sure pfns in
  * the first place.
  */
-typedef uint64_t xen_pfn_t;
+typedef __u64 xen_pfn_t;
 #define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
 #define PRI_xen_ulong "llx"
diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
index 7ddeeda..95b73a9 100644
--- a/include/uapi/xen/privcmd.h
+++ b/include/uapi/xen/privcmd.h
@@ -35,7 +35,19 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
-#include <xen/interface/xen.h>
+
+/* Might be defined by Xen specific headers, but if not */
+#ifndef domid_t
+typedef __u16 domid_t;
+#endif /* domid_t */
+
+#ifndef xen_pfn_t
+#if (defined __ARMEL__ || defined __ARMEB__)
+typedef __u64 xen_pfn_t;
+#else
+typedef unsigned long xen_pfn_t;
+#endif /* (defined __ARMEL__ || defined __ARMEB__) */
+#endif /* xen_pfn_t */
 
 struct privcmd_hypercall {
 	__u64 op;
-- 
2.5.0

[PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

[kbuild test robot]

Hi Mikko,

[auto build test ERROR on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base]

url:    https://github.com/0day-ci/linux/commits/Mikko-Rapeli/Userspace-compile-test-and-fixes-for-exported-uapi-header-files/20151015-150653
config: arm64-allmodconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from drivers/xen/privcmd.c:33:0:
>> include/uapi/xen/privcmd.h:48:23: error: conflicting types for 'xen_pfn_t'
    typedef unsigned long xen_pfn_t;
                          ^
   In file included from arch/arm64/include/asm/xen/interface.h:1:0,
                    from include/xen/interface/xen.h:30,
                    from include/xen/xen.h:23,
                    from arch/arm64/include/asm/io.h:35,
                    from include/linux/bio.h:30,
                    from include/linux/writeback.h:192,
                    from include/linux/memcontrol.h:30,
                    from include/linux/swap.h:8,
                    from drivers/xen/privcmd.c:20:
   arch/arm64/include/../../arm/include/asm/xen/interface.h:39:15: note: previous declaration of 'xen_pfn_t' was here
    typedef __u64 xen_pfn_t;
                  ^

vim +/xen_pfn_t +48 include/uapi/xen/privcmd.h

    42	#endif /* domid_t */
    43	
    44	#ifndef xen_pfn_t
    45	#if (defined __ARMEL__ || defined __ARMEB__)
    46	typedef __u64 xen_pfn_t;
    47	#else
  > 48	typedef unsigned long xen_pfn_t;
    49	#endif /* (defined __ARMEL__ || defined __ARMEB__) */
    50	#endif /* xen_pfn_t */
    51	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 45525 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151015/a5d22f23/attachment-0001.obj>

[PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

[David Vrabel]

On 15/10/15 06:56, Mikko Rapeli wrote:
> xen/interface/xen.h is not exported from kernel headers so remove the
> dependency and provide needed defines for domid_t and xen_pfn_t if they
> are not already defined by some other e.g. Xen specific headers.
> 
> Suggested by Andrew Cooper <andrew.cooper3@citrix.com> on lkml message
> <5569F9C9.8000607@citrix.com>.
> 
> The ifdef for ARM is ugly but did not find better solutions for it.
> 
> Fixes userspace compilation error:
> 
> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory
[...]
> --- a/include/uapi/xen/privcmd.h
> +++ b/include/uapi/xen/privcmd.h
> @@ -35,7 +35,19 @@
>  
>  #include <linux/types.h>
>  #include <linux/compiler.h>
> -#include <xen/interface/xen.h>
> +
> +/* Might be defined by Xen specific headers, but if not */
> +#ifndef domid_t
> +typedef __u16 domid_t;
> +#endif /* domid_t */

As the kbuild bot points out, this does not work since the existence of
a typedef cannot be checked with #ifdef.

I'm not really sure what problem you're trying to solve.  A user space
program making use of this interface gets the domid_t and xen_pfn_t etc
typedefs from the headers provided as part of the libxenctrl library.

David

[PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

[Mikko Rapeli]

On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote:
> On 15/10/15 06:56, Mikko Rapeli wrote:
> > xen/interface/xen.h is not exported from kernel headers so remove the
> > dependency and provide needed defines for domid_t and xen_pfn_t if they
> > are not already defined by some other e.g. Xen specific headers.
> > 
> > Suggested by Andrew Cooper <andrew.cooper3@citrix.com> on lkml message
> > <5569F9C9.8000607@citrix.com>.
> >
> > The ifdef for ARM is ugly but did not find better solutions for it.
> > 
> > Fixes userspace compilation error:
> > 
> > xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory
> [...]
> > --- a/include/uapi/xen/privcmd.h
> > +++ b/include/uapi/xen/privcmd.h
> > @@ -35,7 +35,19 @@
> >  
> >  #include <linux/types.h>
> >  #include <linux/compiler.h>
> > -#include <xen/interface/xen.h>
> > +
> > +/* Might be defined by Xen specific headers, but if not */
> > +#ifndef domid_t
> > +typedef __u16 domid_t;
> > +#endif /* domid_t */
> 
> As the kbuild bot points out, this does not work since the existence of
> a typedef cannot be checked with #ifdef.

Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes:
http://www.spinics.net/lists/linux-api/msg11048.html

> I'm not really sure what problem you're trying to solve.  A user space
> program making use of this interface gets the domid_t and xen_pfn_t etc
> typedefs from the headers provided as part of the libxenctrl library.

I'm trying to make sure that kernel headers in userspace compile with minimal
dependencies which are gcc and libc.

For me it is clear by now that many Linux API's and ABI's like Xen parts do
not live in the uapi header files and instead there's a separate userspace
library with needed headers and defines which have embedded copies of
the needed API and ABI definitions, like header files.

So how could this file be changed so that it compiles in userspace without
definitions from libxenctrl?

I guess I could copy the needed definitions for domid_t and xen_pfn_t from
xen/interface/xen.h of libxenctrl. That I should have done to begin with
instead of trying to hack something on my own.

-Mikko

[PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

[David Vrabel]

On 15/10/15 12:18, Mikko Rapeli wrote:
> On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote:
>> On 15/10/15 06:56, Mikko Rapeli wrote:
>>> xen/interface/xen.h is not exported from kernel headers so remove the
>>> dependency and provide needed defines for domid_t and xen_pfn_t if they
>>> are not already defined by some other e.g. Xen specific headers.
>>>
>>> Suggested by Andrew Cooper <andrew.cooper3@citrix.com> on lkml message
>>> <5569F9C9.8000607@citrix.com>.
>>>
>>> The ifdef for ARM is ugly but did not find better solutions for it.
>>>
>>> Fixes userspace compilation error:
>>>
>>> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory
>> [...]
>>> --- a/include/uapi/xen/privcmd.h
>>> +++ b/include/uapi/xen/privcmd.h
>>> @@ -35,7 +35,19 @@
>>>  
>>>  #include <linux/types.h>
>>>  #include <linux/compiler.h>
>>> -#include <xen/interface/xen.h>
>>> +
>>> +/* Might be defined by Xen specific headers, but if not */
>>> +#ifndef domid_t
>>> +typedef __u16 domid_t;
>>> +#endif /* domid_t */
>>
>> As the kbuild bot points out, this does not work since the existence of
>> a typedef cannot be checked with #ifdef.
> 
> Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes:
> http://www.spinics.net/lists/linux-api/msg11048.html
> 
>> I'm not really sure what problem you're trying to solve.  A user space
>> program making use of this interface gets the domid_t and xen_pfn_t etc
>> typedefs from the headers provided as part of the libxenctrl library.
> 
> I'm trying to make sure that kernel headers in userspace compile with minimal
> dependencies which are gcc and libc.
> 
> For me it is clear by now that many Linux API's and ABI's like Xen parts do
> not live in the uapi header files and instead there's a separate userspace
> library with needed headers and defines which have embedded copies of
> the needed API and ABI definitions, like header files.
> 
> So how could this file be changed so that it compiles in userspace without
> definitions from libxenctrl?

I don't think anything needs to be changed.

Instead I would make your compilation check of this header dependent on
the existence of the xen/interface/xen.h header. Or you may exclude the
check of this header entirely.

> I guess I could copy the needed definitions for domid_t and xen_pfn_t from
> xen/interface/xen.h of libxenctrl. That I should have done to begin with
> instead of trying to hack something on my own.

I do not want definitions duplicated/copied from the hypervisor ABI
headers.  This causes problems when support for new architectures is
added (for example).

David

[PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

[Mikko Rapeli]

On Thu, Oct 15, 2015 at 12:24:39PM +0100, David Vrabel wrote:
> On 15/10/15 12:18, Mikko Rapeli wrote:
> > On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote:
> >> On 15/10/15 06:56, Mikko Rapeli wrote:
> >>> xen/interface/xen.h is not exported from kernel headers so remove the
> >>> dependency and provide needed defines for domid_t and xen_pfn_t if they
> >>> are not already defined by some other e.g. Xen specific headers.
> >>>
> >>> Suggested by Andrew Cooper <andrew.cooper3@citrix.com> on lkml message
> >>> <5569F9C9.8000607@citrix.com>.
> >>>
> >>> The ifdef for ARM is ugly but did not find better solutions for it.
> >>>
> >>> Fixes userspace compilation error:
> >>>
> >>> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory
> >> [...]
> >>> --- a/include/uapi/xen/privcmd.h
> >>> +++ b/include/uapi/xen/privcmd.h
> >>> @@ -35,7 +35,19 @@
> >>>  
> >>>  #include <linux/types.h>
> >>>  #include <linux/compiler.h>
> >>> -#include <xen/interface/xen.h>
> >>> +
> >>> +/* Might be defined by Xen specific headers, but if not */
> >>> +#ifndef domid_t
> >>> +typedef __u16 domid_t;
> >>> +#endif /* domid_t */
> >>
> >> As the kbuild bot points out, this does not work since the existence of
> >> a typedef cannot be checked with #ifdef.
> > 
> > Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes:
> > http://www.spinics.net/lists/linux-api/msg11048.html
> > 
> >> I'm not really sure what problem you're trying to solve.  A user space
> >> program making use of this interface gets the domid_t and xen_pfn_t etc
> >> typedefs from the headers provided as part of the libxenctrl library.
> > 
> > I'm trying to make sure that kernel headers in userspace compile with minimal
> > dependencies which are gcc and libc.
> > 
> > For me it is clear by now that many Linux API's and ABI's like Xen parts do
> > not live in the uapi header files and instead there's a separate userspace
> > library with needed headers and defines which have embedded copies of
> > the needed API and ABI definitions, like header files.
> > 
> > So how could this file be changed so that it compiles in userspace without
> > definitions from libxenctrl?
> 
> I don't think anything needs to be changed.
> 
> Instead I would make your compilation check of this header dependent on
> the existence of the xen/interface/xen.h header. Or you may exclude the
> check of this header entirely.

There are not many headers in uapi which require additional userspace
headers to compile (I'm not saying that uapi headers represent the full
API's/ABI's, it's clear they don't). If there are ~700 headers and just a
single one needs an exception and additional dependencies, I would try to
make it work without the dependency. I just need some advice and guidance
from maintainers how to do this.

Or we should start tracking these userspace library dependencies too,
at least at linux-headers package levels in distributions. This might
be a good idea anyway, but then we might as well move headers like this
directly to the userspace library and out of include/uapi.

Both would solve the non-compiling uapi header problem.

> > I guess I could copy the needed definitions for domid_t and xen_pfn_t from
> > xen/interface/xen.h of libxenctrl. That I should have done to begin with
> > instead of trying to hack something on my own.
> 
> I do not want definitions duplicated/copied from the hypervisor ABI
> headers.  This causes problems when support for new architectures is
> added (for example).

Understood.

-Mikko

> David

[PATCH v4 79/79] arch/arm/include/uapi/asm/signal.h: use __kernel_size_t instead of size_t

[Mikko Rapeli]

Fixes uapi header compilation error from userspace on ARCH=arm:

asm/signal.h:112:2: error: unknown type name ?size_t?
  size_t ss_size;

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 arch/arm/include/uapi/asm/signal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h
index 33073bd..859f2de 100644
--- a/arch/arm/include/uapi/asm/signal.h
+++ b/arch/arm/include/uapi/asm/signal.h
@@ -113,7 +113,7 @@ struct sigaction {
 typedef struct sigaltstack {
 	void __user *ss_sp;
 	int ss_flags;
-	size_t ss_size;
+	__kernel_size_t ss_size;
 } stack_t;
 
 
-- 
2.5.0