Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1467896 > unrolled thread

[PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

Started byMikko Rapeli <mikko.rapeli@iki.fi>
First post2016-08-22 20:40 +0200
Last post2016-08-25 09:50 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h Mikko Rapeli <mikko.rapeli@iki.fi> - 2016-08-22 20:40 +0200
    Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32  and __u64 from linux/types.h Bart Van Assche <Bart.VanAssche@sandisk.com> - 2016-08-23 16:00 +0200
      Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32  and __u64 from linux/types.h Bart Van Assche <Bart.VanAssche@sandisk.com> - 2016-08-23 16:30 +0200
        Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32,  __s32 and __u64 from linux/types.h Mikko Rapeli <mikko.rapeli@iki.fi> - 2016-08-23 22:50 +0200
          Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32  and __u64 from linux/types.h Bart Van Assche <Bart.VanAssche@sandisk.com> - 2016-08-25 07:10 +0200
            Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32,  __s32 and __u64 from linux/types.h Mikko Rapeli <mikko.rapeli@iki.fi> - 2016-08-25 09:50 +0200

#1467896 — [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

FromMikko Rapeli <mikko.rapeli@iki.fi>
Date2016-08-22 20:40 +0200
Subject[PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h
Message-ID<s92iC-1rh-17@gated-at.bofh.it>
Fixes userspace compilation errors like:

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

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/linux/dm-log-userspace.h | 43 ++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/include/uapi/linux/dm-log-userspace.h b/include/uapi/linux/dm-log-userspace.h
index 0fa0d9e..c5ff216 100644
--- a/include/uapi/linux/dm-log-userspace.h
+++ b/include/uapi/linux/dm-log-userspace.h
@@ -7,6 +7,7 @@
 #ifndef __DM_LOG_USERSPACE_H__
 #define __DM_LOG_USERSPACE_H__
 
+#include <linux/types.h>
 #include <linux/dm-ioctl.h> /* For DM_UUID_LEN */
 
 /*
@@ -147,12 +148,12 @@
 
 /*
  * DM_ULOG_GET_REGION_SIZE corresponds to (found in dm-dirty-log.h):
- * uint32_t (*get_region_size)(struct dm_dirty_log *log);
+ * __u32 (*get_region_size)(struct dm_dirty_log *log);
  *
  * Payload-to-userspace:
  *	None.
  * Payload-to-kernel:
- *	uint64_t - contains the region size
+ *	__u64 - contains the region size
  *
  * The region size is something that was determined at constructor time.
  * It is returned in the payload area and 'data_size' is set to
@@ -168,11 +169,11 @@
  * int (*is_clean)(struct dm_dirty_log *log, region_t region);
  *
  * Payload-to-userspace:
- *	uint64_t - the region to get clean status on
+ *	__u64 - the region to get clean status on
  * Payload-to-kernel:
  *	int64_t  - 1 if clean, 0 otherwise
  *
- * Payload is sizeof(uint64_t) and contains the region for which the clean
+ * Payload is sizeof(__u64) and contains the region for which the clean
  * status is being made.
  *
  * When the request has been processed, user-space must return the
@@ -187,7 +188,7 @@
  *		  int can_block);
  *
  * Payload-to-userspace:
- *	uint64_t - the region to get sync status on
+ *	__u64 - the region to get sync status on
  * Payload-to-kernel:
  *	int64_t - 1 if in-sync, 0 otherwise
  *
@@ -203,7 +204,7 @@
  * Payload-to-userspace:
  *	If the 'integrated_flush' directive is present in the constructor
  *	table, the payload is as same as DM_ULOG_MARK_REGION:
- *		uint64_t [] - region(s) to mark
+ *		__u64 [] - region(s) to mark
  *	else
  *		None
  * Payload-to-kernel:
@@ -225,13 +226,13 @@
  * void (*mark_region)(struct dm_dirty_log *log, region_t region);
  *
  * Payload-to-userspace:
- *	uint64_t [] - region(s) to mark
+ *	__u64 [] - region(s) to mark
  * Payload-to-kernel:
  *	None.
  *
  * Incoming payload contains the one or more regions to mark dirty.
  * The number of regions contained in the payload can be determined from
- * 'data_size/sizeof(uint64_t)'.
+ * 'data_size/sizeof(__u64)'.
  *
  * When the request has been processed, user-space must return the
  * dm_ulog_request to the kernel - setting the 'error' field and clearing
@@ -244,13 +245,13 @@
  * void (*clear_region)(struct dm_dirty_log *log, region_t region);
  *
  * Payload-to-userspace:
- *	uint64_t [] - region(s) to clear
+ *	__u64 [] - region(s) to clear
  * Payload-to-kernel:
  *	None.
  *
  * Incoming payload contains the one or more regions to mark clean.
  * The number of regions contained in the payload can be determined from
- * 'data_size/sizeof(uint64_t)'.
+ * 'data_size/sizeof(__u64)'.
  *
  * When the request has been processed, user-space must return the
  * dm_ulog_request to the kernel - setting the 'error' field and clearing
@@ -267,7 +268,7 @@
  * Payload-to-kernel:
  *	{
  *		int64_t i; -- 1 if recovery necessary, 0 otherwise
- *		uint64_t r; -- The region to recover if i=1
+ *		__u64 r; -- The region to recover if i=1
  *	}
  * 'data_size' should be set appropriately.
  *
@@ -283,7 +284,7 @@
  *
  * Payload-to-userspace:
  *	{
- *		uint64_t - region to set sync state on
+ *		__u64 - region to set sync state on
  *		int64_t  - 0 if not-in-sync, 1 if in-sync
  *	}
  * Payload-to-kernel:
@@ -302,7 +303,7 @@
  * Payload-to-userspace:
  *	None.
  * Payload-to-kernel:
- *	uint64_t - the number of in-sync regions
+ *	__u64 - the number of in-sync regions
  *
  * No incoming payload.  Kernel-bound payload contains the number of
  * regions that are in-sync (in a size_t).
@@ -350,11 +351,11 @@
  * int (*is_remote_recovering)(struct dm_dirty_log *log, region_t region);
  *
  * Payload-to-userspace:
- *	uint64_t - region to determine recovery status on
+ *	__u64 - region to determine recovery status on
  * Payload-to-kernel:
  *	{
  *		int64_t is_recovering;  -- 0 if no, 1 if yes
- *		uint64_t in_sync_hint;  -- lowest region still needing resync
+ *		__u64 in_sync_hint;  -- lowest region still needing resync
  *	}
  *
  * When the request has been processed, user-space must return the
@@ -413,16 +414,16 @@ struct dm_ulog_request {
 	 * differentiate between logs that are being swapped and have the
 	 * same 'uuid'.  (Think "live" and "inactive" device-mapper tables.)
 	 */
-	uint64_t luid;
+	__u64 luid;
 	char uuid[DM_UUID_LEN];
 	char padding[3];        /* Padding because DM_UUID_LEN = 129 */
 
-	uint32_t version;       /* See DM_ULOG_REQUEST_VERSION */
-	int32_t error;          /* Used to report back processing errors */
+	__u32 version;       /* See DM_ULOG_REQUEST_VERSION */
+	__s32 error;          /* Used to report back processing errors */
 
-	uint32_t seq;           /* Sequence number for request */
-	uint32_t request_type;  /* DM_ULOG_* defined above */
-	uint32_t data_size;     /* How much data (not including this struct) */
+	__u32 seq;           /* Sequence number for request */
+	__u32 request_type;  /* DM_ULOG_* defined above */
+	__u32 data_size;     /* How much data (not including this struct) */
 
 	char data[0];
 };
-- 
2.8.1

[toc] | [next] | [standalone]

#1468565 — Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

FromBart Van Assche <Bart.VanAssche@sandisk.com>
Date2016-08-23 16:00 +0200
SubjectRe: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h
Message-ID<s9kpb-4K7-19@gated-at.bofh.it>
In reply to#1467896
On 08/22/16 11:32, Mikko Rapeli wrote:
> - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
> + * __u32 (*get_region_size)(struct dm_dirty_log *log);

uint32_t is a type that is defined by ANSI C but __u32 not. So this 
change looks wrong to me. Would it have been sufficient to add "#include 
<linux/types.h>" and keep the uint32_t etc. type names?

Bart.

[toc] | [prev] | [next] | [standalone]

#1468590 — Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

FromBart Van Assche <Bart.VanAssche@sandisk.com>
Date2016-08-23 16:30 +0200
SubjectRe: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h
Message-ID<s9kSd-5aF-9@gated-at.bofh.it>
In reply to#1468565
On 08/23/16 06:57, Bart Van Assche wrote:
> On 08/22/16 11:32, Mikko Rapeli wrote:
>> - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
>> + * __u32 (*get_region_size)(struct dm_dirty_log *log);
>
> uint32_t is a type that is defined by ANSI C but __u32 not. So this
> change looks wrong to me. Would it have been sufficient to add "#include
> <linux/types.h>" and keep the uint32_t etc. type names?

Answering my own question: adding "#include <linux/types.h>" wouldn't be 
sufficient. How about adding the following code that also occurs in a 
few other uapi header files?

#ifndef __KERNEL__
#include <stdint.h>
#endif
#include <linux/types.h>

Bart.

[toc] | [prev] | [next] | [standalone]

#1468839 — Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

FromMikko Rapeli <mikko.rapeli@iki.fi>
Date2016-08-23 22:50 +0200
SubjectRe: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h
Message-ID<s9qNY-Dm-23@gated-at.bofh.it>
In reply to#1468590
On Tue, Aug 23, 2016 at 02:28:19PM +0000, Bart Van Assche wrote:
> On 08/23/16 06:57, Bart Van Assche wrote:
> > On 08/22/16 11:32, Mikko Rapeli wrote:
> >> - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
> >> + * __u32 (*get_region_size)(struct dm_dirty_log *log);
> >
> > uint32_t is a type that is defined by ANSI C but __u32 not. So this
> > change looks wrong to me. Would it have been sufficient to add "#include
> > <linux/types.h>" and keep the uint32_t etc. type names?
> 
> Answering my own question: adding "#include <linux/types.h>" wouldn't be 
> sufficient. How about adding the following code that also occurs in a 
> few other uapi header files?
> 
> #ifndef __KERNEL__
> #include <stdint.h>
> #endif
> #include <linux/types.h>

I have tried that before but I was instructed to use the linux/types.h
versions. For example https://lkml.org/lkml/2015/6/1/160

But lately drm and fuse and some others have questioned this approach and
would like to use/continue using C99 stdint.h types.

-Mikko

[toc] | [prev] | [next] | [standalone]

#1469834 — Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

FromBart Van Assche <Bart.VanAssche@sandisk.com>
Date2016-08-25 07:10 +0200
SubjectRe: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h
Message-ID<s9V5o-50Y-11@gated-at.bofh.it>
In reply to#1468839
On 08/23/16 13:42, Mikko Rapeli wrote:
> On Tue, Aug 23, 2016 at 02:28:19PM +0000, Bart Van Assche wrote:
>> On 08/23/16 06:57, Bart Van Assche wrote:
>>> On 08/22/16 11:32, Mikko Rapeli wrote:
>>>> - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
>>>> + * __u32 (*get_region_size)(struct dm_dirty_log *log);
>>>
>>> uint32_t is a type that is defined by ANSI C but __u32 not. So this
>>> change looks wrong to me. Would it have been sufficient to add "#include
>>> <linux/types.h>" and keep the uint32_t etc. type names?
>>
>> Answering my own question: adding "#include <linux/types.h>" wouldn't be
>> sufficient. How about adding the following code that also occurs in a
>> few other uapi header files?
>>
>> #ifndef __KERNEL__
>> #include <stdint.h>
>> #endif
>> #include <linux/types.h>
>
> I have tried that before but I was instructed to use the linux/types.h
> versions. For example https://lkml.org/lkml/2015/6/1/160
>
> But lately drm and fuse and some others have questioned this approach and
> would like to use/continue using C99 stdint.h types.

Hello Mikko,

Thanks for the feedback. I have a minor comment though about your patch: 
are you aware that you have changed uint64_t into __u64 in source code 
comments but that int64_t has not been changed into __s64?

Bart.

[toc] | [prev] | [next] | [standalone]

#1469935 — Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

FromMikko Rapeli <mikko.rapeli@iki.fi>
Date2016-08-25 09:50 +0200
SubjectRe: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h
Message-ID<s9XAe-6uu-33@gated-at.bofh.it>
In reply to#1469834
On Thu, Aug 25, 2016 at 04:24:11AM +0000, Bart Van Assche wrote:
> On 08/23/16 13:42, Mikko Rapeli wrote:
> > On Tue, Aug 23, 2016 at 02:28:19PM +0000, Bart Van Assche wrote:
> >> On 08/23/16 06:57, Bart Van Assche wrote:
> >>> On 08/22/16 11:32, Mikko Rapeli wrote:
> >>>> - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
> >>>> + * __u32 (*get_region_size)(struct dm_dirty_log *log);
> >>>
> >>> uint32_t is a type that is defined by ANSI C but __u32 not. So this
> >>> change looks wrong to me. Would it have been sufficient to add "#include
> >>> <linux/types.h>" and keep the uint32_t etc. type names?
> >>
> >> Answering my own question: adding "#include <linux/types.h>" wouldn't be
> >> sufficient. How about adding the following code that also occurs in a
> >> few other uapi header files?
> >>
> >> #ifndef __KERNEL__
> >> #include <stdint.h>
> >> #endif
> >> #include <linux/types.h>
> >
> > I have tried that before but I was instructed to use the linux/types.h
> > versions. For example https://lkml.org/lkml/2015/6/1/160
> >
> > But lately drm and fuse and some others have questioned this approach and
> > would like to use/continue using C99 stdint.h types.
> 
> Hello Mikko,
> 
> Thanks for the feedback. I have a minor comment though about your patch: 
> are you aware that you have changed uint64_t into __u64 in source code 
> comments but that int64_t has not been changed into __s64?

Thanks, that's a bug. I'll update the patch.

I guess I was reading compiler error list and string replacing only those.

-Mikko

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web