staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

PATCH New Roman Storozhenko 3 participants 8 messages Oct 29, 2017 – Nov 13, 2017 Staging

Share & tools

Roman Storozhenko

author

2017-10-29 17:58 UTC #0 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html

2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.

Signed-off-by Roman Storozhenko <[email protected]>

---
 drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
 drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
 drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
 drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

drivers/staging/lustre/lustre/include/lustre_sec.h +2 -2

index 03a970b..c616ae5 100644
@@ -340,8 +340,8 @@ void sptlrpc_conf_client_adapt(struct obd_device *obd);
 #define SPTLRPC_MAX_PAYLOAD     (1024)
 
 struct vfs_cred {
-	uint32_t	vc_uid;
-	uint32_t	vc_gid;
+	__u32	vc_uid;
+	__u32	vc_gid;
 };
 
 struct ptlrpc_ctx_ops {

drivers/staging/lustre/lustre/llite/vvp_dev.c +1 -1

index f9d9a16..9a98a95 100644
@@ -383,7 +383,7 @@ int cl_sb_fini(struct super_block *sb)
 struct vvp_pgcache_id {
 	unsigned int		 vpi_bucket;
 	unsigned int		 vpi_depth;
-	uint32_t		 vpi_index;
+	__u32			 vpi_index;
 
 	unsigned int		 vpi_curdep;
 	struct lu_object_header *vpi_obj;

drivers/staging/lustre/lustre/lov/lov_internal.h +6 -6

index a21f074..49a106c 100644
@@ -114,19 +114,19 @@ static inline const struct lsm_operations *lsm_op_find(int magic)
  */
 #if BITS_PER_LONG == 64
 # define lov_do_div64(n, base) ({					\
-	uint64_t __base = (base);					\
-	uint64_t __rem;							\
-	__rem = ((uint64_t)(n)) % __base;				\
-	(n) = ((uint64_t)(n)) / __base;					\
+	__u64 __base = (base);						\
+	__u64 __rem;							\
+	__rem = ((__u64)(n)) % __base;				\
+	(n) = ((__u64)(n)) / __base;					\
 	__rem;								\
 })
 #elif BITS_PER_LONG == 32
 # define lov_do_div64(n, base) ({					\
-	uint64_t __rem;							\
+	__u64 __rem;							\
 	if ((sizeof(base) > 4) && (((base) & 0xffffffff00000000ULL) != 0)) {  \
 		int __remainder;					      \
 		LASSERTF(!((base) & (LOV_MIN_STRIPE_SIZE - 1)), "64 bit lov " \
-			 "division %llu / %llu\n", (n), (uint64_t)(base));    \
+			 "division %llu / %llu\n", (n), (__u64)(base));    \
 		__remainder = (n) & (LOV_MIN_STRIPE_SIZE - 1);		\
 		(n) >>= LOV_MIN_STRIPE_BITS;				\
 		__rem = do_div(n, (base) >> LOV_MIN_STRIPE_BITS);	\

drivers/staging/lustre/lustre/osc/osc_internal.h +3 -3

index a536908..92d2e1f 100644
@@ -167,9 +167,9 @@ struct osc_device {
 
 	/* Write stats is actually protected by client_obd's lock. */
 	struct osc_stats {
-		uint64_t     os_lockless_writes;	  /* by bytes */
-		uint64_t     os_lockless_reads;	   /* by bytes */
-		uint64_t     os_lockless_truncates;       /* by times */
+		__u64     os_lockless_writes;	  /* by bytes */
+		__u64     os_lockless_reads;	   /* by bytes */
+		__u64     os_lockless_truncates;       /* by times */
 	} od_stats;
 
 	/* configuration item(s) */

Signature · 1 line

2.7.4

Dilger

2017-10-31 07:44 UTC #1 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

Quoted 9 lines · Roman Storozhenko

There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.
Signed-off-by Roman Storozhenko <[email protected]>

Reviewed-by Andreas Dilger <[email protected]>

Quoted 85 lines

---

drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)

drivers/staging/lustre/lustre/include/lustre_sec.h +2 -2

index 03a970b..c616ae5 100644
@@ -340,8 +340,8 @@ void sptlrpc_conf_client_adapt(struct obd_device *obd);
 #define SPTLRPC_MAX_PAYLOAD     (1024)
 
 struct vfs_cred {
-	uint32_t	vc_uid;
-	uint32_t	vc_gid;
+	__u32	vc_uid;
+	__u32	vc_gid;
 };
 
 struct ptlrpc_ctx_ops {

drivers/staging/lustre/lustre/llite/vvp_dev.c +1 -1

index f9d9a16..9a98a95 100644
@@ -383,7 +383,7 @@ int cl_sb_fini(struct super_block *sb)
 struct vvp_pgcache_id {
 	unsigned int		 vpi_bucket;
 	unsigned int		 vpi_depth;
-	uint32_t		 vpi_index;
+	__u32			 vpi_index;
 
 	unsigned int		 vpi_curdep;
 	struct lu_object_header *vpi_obj;

drivers/staging/lustre/lustre/lov/lov_internal.h +6 -6

index a21f074..49a106c 100644
@@ -114,19 +114,19 @@ static inline const struct lsm_operations *lsm_op_find(int magic)
 */
 #if BITS_PER_LONG == 64
 # define lov_do_div64(n, base) ({					\
-	uint64_t __base = (base);					\
-	uint64_t __rem;							\
-	__rem = ((uint64_t)(n)) % __base;				\
-	(n) = ((uint64_t)(n)) / __base;					\
+	__u64 __base = (base);						\
+	__u64 __rem;							\
+	__rem = ((__u64)(n)) % __base;				\
+	(n) = ((__u64)(n)) / __base;					\
 	__rem;								\
 })
 #elif BITS_PER_LONG == 32
 # define lov_do_div64(n, base) ({					\
-	uint64_t __rem;							\
+	__u64 __rem;							\
 	if ((sizeof(base) > 4) && (((base) & 0xffffffff00000000ULL) != 0)) {  \
 		int __remainder;					      \
 		LASSERTF(!((base) & (LOV_MIN_STRIPE_SIZE - 1)), "64 bit lov " \
-			 "division %llu / %llu\n", (n), (uint64_t)(base));    \
+			 "division %llu / %llu\n", (n), (__u64)(base));    \
 		__remainder = (n) & (LOV_MIN_STRIPE_SIZE - 1);		\
 		(n) >>= LOV_MIN_STRIPE_BITS;				\
 		__rem = do_div(n, (base) >> LOV_MIN_STRIPE_BITS);	\

drivers/staging/lustre/lustre/osc/osc_internal.h +3 -3

index a536908..92d2e1f 100644
@@ -167,9 +167,9 @@ struct osc_device {
 
 	/* Write stats is actually protected by client_obd's lock. */
 	struct osc_stats {
-		uint64_t     os_lockless_writes;	  /* by bytes */
-		uint64_t     os_lockless_reads;	   /* by bytes */
-		uint64_t     os_lockless_truncates;       /* by times */
+		__u64     os_lockless_writes;	  /* by bytes */
+		__u64     os_lockless_reads;	   /* by bytes */
+		__u64     os_lockless_truncates;       /* by times */
 	} od_stats;
 
 	/* configuration item(s) */

Signature · 1 line

2.7.4

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Dilger

2017-11-01 02:01 UTC #2 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

In reply to Roman Storozhenko

Quoted 9 lines · Roman Storozhenko

There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.
Signed-off-by Roman Storozhenko <[email protected]>

Reviewed-by Andreas Dilger <[email protected]>

Quoted 85 lines

---

drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)

drivers/staging/lustre/lustre/include/lustre_sec.h +2 -2

index 03a970b..c616ae5 100644
@@ -340,8 +340,8 @@ void sptlrpc_conf_client_adapt(struct obd_device *obd);
 #define SPTLRPC_MAX_PAYLOAD     (1024)
 
 struct vfs_cred {
-	uint32_t	vc_uid;
-	uint32_t	vc_gid;
+	__u32	vc_uid;
+	__u32	vc_gid;
 };
 
 struct ptlrpc_ctx_ops {

drivers/staging/lustre/lustre/llite/vvp_dev.c +1 -1

index f9d9a16..9a98a95 100644
@@ -383,7 +383,7 @@ int cl_sb_fini(struct super_block *sb)
 struct vvp_pgcache_id {
 	unsigned int		 vpi_bucket;
 	unsigned int		 vpi_depth;
-	uint32_t		 vpi_index;
+	__u32			 vpi_index;
 
 	unsigned int		 vpi_curdep;
 	struct lu_object_header *vpi_obj;

drivers/staging/lustre/lustre/lov/lov_internal.h +6 -6

index a21f074..49a106c 100644
@@ -114,19 +114,19 @@ static inline const struct lsm_operations *lsm_op_find(int magic)
 */
 #if BITS_PER_LONG == 64
 # define lov_do_div64(n, base) ({					\
-	uint64_t __base = (base);					\
-	uint64_t __rem;							\
-	__rem = ((uint64_t)(n)) % __base;				\
-	(n) = ((uint64_t)(n)) / __base;					\
+	__u64 __base = (base);						\
+	__u64 __rem;							\
+	__rem = ((__u64)(n)) % __base;				\
+	(n) = ((__u64)(n)) / __base;					\
 	__rem;								\
 })
 #elif BITS_PER_LONG == 32
 # define lov_do_div64(n, base) ({					\
-	uint64_t __rem;							\
+	__u64 __rem;							\
 	if ((sizeof(base) > 4) && (((base) & 0xffffffff00000000ULL) != 0)) {  \
 		int __remainder;					      \
 		LASSERTF(!((base) & (LOV_MIN_STRIPE_SIZE - 1)), "64 bit lov " \
-			 "division %llu / %llu\n", (n), (uint64_t)(base));    \
+			 "division %llu / %llu\n", (n), (__u64)(base));    \
 		__remainder = (n) & (LOV_MIN_STRIPE_SIZE - 1);		\
 		(n) >>= LOV_MIN_STRIPE_BITS;				\
 		__rem = do_div(n, (base) >> LOV_MIN_STRIPE_BITS);	\

drivers/staging/lustre/lustre/osc/osc_internal.h +3 -3

index a536908..92d2e1f 100644
@@ -167,9 +167,9 @@ struct osc_device {
 
 	/* Write stats is actually protected by client_obd's lock. */
 	struct osc_stats {
-		uint64_t     os_lockless_writes;	  /* by bytes */
-		uint64_t     os_lockless_reads;	   /* by bytes */
-		uint64_t     os_lockless_truncates;       /* by times */
+		__u64     os_lockless_writes;	  /* by bytes */
+		__u64     os_lockless_reads;	   /* by bytes */
+		__u64     os_lockless_truncates;       /* by times */
 	} od_stats;
 
 	/* configuration item(s) */

Signature · 1 line

2.7.4

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Greg Kroah-Hartman

maintainer

2017-11-03 11:46 UTC #3 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

In reply to Roman Storozhenko

Quoted 6 lines · Roman Storozhenko

There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.

The __ types are only needed for when you cross the user/kernel boundry. Otherwise just use the "normal" types of u32 and u64.

Do the changes you made here all cross that boundry? If not, please fix this up.

thanks,

greg k-h

Roman Storozhenko

author

2017-11-03 12:36 UTC #4 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

Quoted 5 lines · Greg Kroah-Hartman

Quoted 4 lines · Roman Storozhenko
There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html

Quoted 8 lines

Quoted 2 lines
2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.
The __ types are only needed for when you cross the user/kernel boundry. Otherwise just use the "normal" types of u32 and u64.
Do the changes you made here all cross that boundry? If not, please fix this up.

Thanks, Greg.

I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?

Quoted 4 lines

thanks,
greg k-h

Dilger

2017-11-09 10:06 UTC #5 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

Quoted 19 lines · Roman Storozhenko

Quoted 17 lines · Greg Kroah-Hartman
Quoted 4 lines · Roman Storozhenko
There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
Quoted 8 lines
2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.
drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
The __ types are only needed for when you cross the user/kernel boundry. Otherwise just use the "normal" types of u32 and u64.

Quoted 6 lines

Quoted 2 lines
Do the changes you made here all cross that boundry? If not, please fix this up.
Thanks, Greg.
I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?

Sorry for not getting back to you sooner, I was traveling.

I'm not sure what you mean by the .h files aren't used in client code? I checked all of the headers, and all of the structures that were changed, and they all looked to be in use.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Roman Storozhenko

author

2017-11-09 10:57 UTC #6 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

Quoted 25 lines · Andreas

Quoted 24 lines · Roman Storozhenko
Quoted 14 lines · Greg Kroah-Hartman
Quoted 4 lines · Roman Storozhenko
There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
Quoted 8 lines
2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.
drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
Quoted 5 lines
The __ types are only needed for when you cross the user/kernel boundry. Otherwise just use the "normal" types of u32 and u64.
Do the changes you made here all cross that boundry? If not, please fix this up.
Thanks, Greg.

Quoted 7 lines

Quoted 1 line
I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?
Sorry for not getting back to you sooner, I was traveling.
I'm not sure what you mean by the .h files aren't used in client code? I checked all of the headers, and all of the structures that were changed, and they all looked to be in use.

Thanks, Andreas. But let me clarify: did you mean that those structures are being used in userspace code and this patch could be accepted?
Or those structures are being used only in the kernel code and I should change it according to Greg's remark?

Kind regards,
Roman

Quoted 13 lines

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Signature · 2 lines

Kind regards,
Roman

Dilger

2017-11-13 17:04 UTC #7 lore raw

PATCH 1/1 staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

Quoted 38 lines · Roman Storozhenko

Quoted 25 lines · Andreas
Quoted 24 lines · Roman Storozhenko
Quoted 14 lines · Greg Kroah-Hartman
Quoted 4 lines · Roman Storozhenko
There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
Quoted 8 lines
2) There are only few places in the lustre codebase that use such types. In the most cases it uses '__u32' and '__u64'.
drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
Quoted 5 lines
The __ types are only needed for when you cross the user/kernel boundry. Otherwise just use the "normal" types of u32 and u64.
Do the changes you made here all cross that boundry? If not, please fix this up.
Thanks, Greg.
Quoted 7 lines
Quoted 1 line
I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?
Sorry for not getting back to you sooner, I was traveling.
I'm not sure what you mean by the .h files aren't used in client code? I checked all of the headers, and all of the structures that were changed, and they all looked to be in use.

Quoted 5 lines

Thanks, Andreas. But let me clarify: did you mean that those structures are being used in userspace code and this patch could be accepted?
Or those structures are being used only in the kernel code and I should change it according to Greg's remark?

These headers are for kernel code only, so should use the "u32" and similar types, rather than the "__u32" that are used for user-kernel structures.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation