dm-log-userspace.h: include stdint.h in userspace

Fixes compilation error:

linux/dm-log-userspace.h:416:2: error: unknown type name ‘uint64_t’

Signed-off-by: Mikko Rapeli <redacted>
---
 include/uapi/linux/dm-log-userspace.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/dm-log-userspace.h b/include/uapi/linux/dm-log-userspace.h
index 0fa0d9e..7b9684e 100644
--- a/include/uapi/linux/dm-log-userspace.h
+++ b/include/uapi/linux/dm-log-userspace.h

@@ -7,6 +7,11 @@
 #ifndef __DM_LOG_USERSPACE_H__
 #define __DM_LOG_USERSPACE_H__
 
+#ifdef __KERNEL__
+#include <linux/types.h>
+#else
+#include <stdint.h>
+#endif
 #include <linux/dm-ioctl.h> /* For DM_UUID_LEN */
 
 /*

-- 
2.1.4

On Mon, Feb 16 2015 at  6:05pm -0500,
Mikko Rapeli [off-list ref] wrote:

Fixes compilation error:

linux/dm-log-userspace.h:416:2: error: unknown type name ‘uint64_t’

What userspace code are you compiling?  Do you have a feel for when this
stopped working?

On Mon, Feb 16, 2015 at 06:32:54PM -0500, Mike Snitzer wrote:

On Mon, Feb 16 2015 at  6:05pm -0500,
Mikko Rapeli [off-list ref] wrote:

quoted

Fixes compilation error:

linux/dm-log-userspace.h:416:2: error: unknown type name ‘uint64_t’

What userspace code are you compiling?  Do you have a feel for when this
stopped working?

See Message-Id: [off-list ref]
or https://lkml.org/lkml/2015/2/16/521

The failure comes from a test which tries to compile each exported header file
in userspace one at a time.

-Mikko

On Tuesday 17 February 2015 00:05:18 Mikko Rapeli wrote:

The normal way to do this in kernel headers is to use linux/types.h
but change the data structures to use __u64 instead of uint64_t
to avoid the build error.

It's possible that the maintainers of this code have a strong opinion
on this matter, but try doing that first.

	Arnd

On Tue, Feb 17, 2015 at 10:08:56AM +0100, Arnd Bergmann wrote:

The normal way to do this in kernel headers is to use linux/types.h
but change the data structures to use __u64 instead of uint64_t
to avoid the build error.

 
That's what happened to dm-ioctl.h.
(Or someone could adjust linux/types.h to include these as standard.)

Alasdair

On Tuesday 17 February 2015 13:38:06 Alasdair G Kergon wrote:

On Tue, Feb 17, 2015 at 10:08:56AM +0100, Arnd Bergmann wrote:

quoted

The normal way to do this in kernel headers is to use linux/types.h
but change the data structures to use __u64 instead of uint64_t
to avoid the build error.

 
That's what happened to dm-ioctl.h.

Ah, indeed. It turns out that it was my own change that did this:


commit 9adfbfb611307060db54691bc7e6d53fdc12312b
Author: Arnd Bergmann [off-list ref]
Date:   Thu Feb 26 00:51:40 2009 +0100

    make most exported headers use strict integer types
    
    This takes care of all files that have only a small number
    of non-strict integer type uses.

(Or someone could adjust linux/types.h to include these as standard.)

No, that wouldn't work. The C user space headers are not meant to
be included implicitly by any standard headers, which might pull
in linux/types.h implicitly.

I think it would be best to change all patches in the new series
in the same way for consistency and try to avoid using stdint.h
as much as we can.

	Arnd

On Tue, Feb 17, 2015 at 02:55:49PM +0100, Arnd Bergmann wrote:

On Tuesday 17 February 2015 13:38:06 Alasdair G Kergon wrote:

quoted

On Tue, Feb 17, 2015 at 10:08:56AM +0100, Arnd Bergmann wrote:

quoted

The normal way to do this in kernel headers is to use linux/types.h
but change the data structures to use __u64 instead of uint64_t
to avoid the build error.

 
That's what happened to dm-ioctl.h.

Ah, indeed. It turns out that it was my own change that did this:


commit 9adfbfb611307060db54691bc7e6d53fdc12312b
Author: Arnd Bergmann [off-list ref]
Date:   Thu Feb 26 00:51:40 2009 +0100

    make most exported headers use strict integer types
    
    This takes care of all files that have only a small number
    of non-strict integer type uses.

quoted

(Or someone could adjust linux/types.h to include these as standard.)

No, that wouldn't work. The C user space headers are not meant to
be included implicitly by any standard headers, which might pull
in linux/types.h implicitly.

I think it would be best to change all patches in the new series
in the same way for consistency and try to avoid using stdint.h
as much as we can.

Ok, I'll change all patches to use __u8 etc types instead of uint8_t etc via
stdint.h.

-Mikko