[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[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 <romeusmeister@gmail.com>

---
 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(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_sec.h b/drivers/staging/lustre/lustre/include/lustre_sec.h
index 03a970b..c616ae5 100644
--- a/drivers/staging/lustre/lustre/include/lustre_sec.h
+++ b/drivers/staging/lustre/lustre/include/lustre_sec.h
@@ -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 {
diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c b/drivers/staging/lustre/lustre/llite/vvp_dev.c
index f9d9a16..9a98a95 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
@@ -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;
diff --git a/drivers/staging/lustre/lustre/lov/lov_internal.h b/drivers/staging/lustre/lustre/lov/lov_internal.h
index a21f074..49a106c 100644
--- a/drivers/staging/lustre/lustre/lov/lov_internal.h
+++ b/drivers/staging/lustre/lustre/lov/lov_internal.h
@@ -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);	\
diff --git a/drivers/staging/lustre/lustre/osc/osc_internal.h b/drivers/staging/lustre/lustre/osc/osc_internal.h
index a536908..92d2e1f 100644
--- a/drivers/staging/lustre/lustre/osc/osc_internal.h
+++ b/drivers/staging/lustre/lustre/osc/osc_internal.h
@@ -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) */
-- 
2.7.4

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[Dilger, Andreas]

On Oct 30, 2017, at 01:58, Roman Storozhenko <romeusmeister@gmail.com> wrote:
> 
> 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 <romeusmeister@gmail.com>

Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>

> ---
> 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(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/lustre_sec.h b/drivers/staging/lustre/lustre/include/lustre_sec.h
> index 03a970b..c616ae5 100644
> --- a/drivers/staging/lustre/lustre/include/lustre_sec.h
> +++ b/drivers/staging/lustre/lustre/include/lustre_sec.h
> @@ -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 {
> diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> index f9d9a16..9a98a95 100644
> --- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
> +++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> @@ -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;
> diff --git a/drivers/staging/lustre/lustre/lov/lov_internal.h b/drivers/staging/lustre/lustre/lov/lov_internal.h
> index a21f074..49a106c 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_internal.h
> +++ b/drivers/staging/lustre/lustre/lov/lov_internal.h
> @@ -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);	\
> diff --git a/drivers/staging/lustre/lustre/osc/osc_internal.h b/drivers/staging/lustre/lustre/osc/osc_internal.h
> index a536908..92d2e1f 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_internal.h
> +++ b/drivers/staging/lustre/lustre/osc/osc_internal.h
> @@ -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) */
> -- 
> 2.7.4
> 

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

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[Dilger, Andreas]

On Oct 30, 2017, at 01:58, Roman Storozhenko <romeusmeister@gmail.com> wrote:
> 
> 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 <romeusmeister@gmail.com>

Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>

> ---
> 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(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/lustre_sec.h b/drivers/staging/lustre/lustre/include/lustre_sec.h
> index 03a970b..c616ae5 100644
> --- a/drivers/staging/lustre/lustre/include/lustre_sec.h
> +++ b/drivers/staging/lustre/lustre/include/lustre_sec.h
> @@ -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 {
> diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> index f9d9a16..9a98a95 100644
> --- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
> +++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> @@ -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;
> diff --git a/drivers/staging/lustre/lustre/lov/lov_internal.h b/drivers/staging/lustre/lustre/lov/lov_internal.h
> index a21f074..49a106c 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_internal.h
> +++ b/drivers/staging/lustre/lustre/lov/lov_internal.h
> @@ -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);	\
> diff --git a/drivers/staging/lustre/lustre/osc/osc_internal.h b/drivers/staging/lustre/lustre/osc/osc_internal.h
> index a536908..92d2e1f 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_internal.h
> +++ b/drivers/staging/lustre/lustre/osc/osc_internal.h
> @@ -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) */
> -- 
> 2.7.4
> 

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

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[Greg Kroah-Hartman]

On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
> 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

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[Roman Storozhenko]

On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
> > 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.

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?

> 
> thanks,
> 
> greg k-h

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[Dilger, Andreas]

On Nov 3, 2017, at 06:36, Roman Storozhenko <romeusmeister@gmail.com> wrote:
> 
> On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
>> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
>>> 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'.
>> 
>>> 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.
>> 
>> 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

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[Roman Storozhenko]

On Thu, Nov 9, 2017 at 1:06 PM, Dilger, Andreas
<andreas.dilger@intel.com> wrote:
> On Nov 3, 2017, at 06:36, Roman Storozhenko <romeusmeister@gmail.com> wrote:
>>
>> On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
>>>> 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'.
>>>
>>>> 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.
>>>
>>> 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.

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

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



-- 
Kind regards,
Roman

[lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t' with '__u32' and 'uint64_t' with '__u64'.

[Dilger, Andreas]

> On Nov 9, 2017, at 03:57, Roman Storozhenko <romeusmeister@gmail.com> wrote:
> 
> On Thu, Nov 9, 2017 at 1:06 PM, Dilger, Andreas
> <andreas.dilger@intel.com> wrote:
>> On Nov 3, 2017, at 06:36, Roman Storozhenko <romeusmeister@gmail.com> wrote:
>>> 
>>> On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
>>>> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
>>>>> 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'.
>>>> 
>>>>> 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.
>>>> 
>>>> 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.
> 
> 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