[PATCH 1/3] int-ll64.h: define u{8,16,32,64} and s{8,16,32,64} based on uapi header

[PATCH 1/3] int-ll64.h: define u{8,16,32,64} and s{8,16,32,64} based on uapi header

[Masahiro Yamada]

<uapi/asm-generic/int-ll64.h> has the same typedefs except that it
prefixes them with double-underscore for user space.  Use them for
the kernel space typedefs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 include/asm-generic/int-ll64.h | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/include/asm-generic/int-ll64.h b/include/asm-generic/int-ll64.h
index ffb68d6..a248545 100644
--- a/include/asm-generic/int-ll64.h
+++ b/include/asm-generic/int-ll64.h
@@ -13,17 +13,14 @@
 
 #ifndef __ASSEMBLY__
 
-typedef signed char s8;
-typedef unsigned char u8;
-
-typedef signed short s16;
-typedef unsigned short u16;
-
-typedef signed int s32;
-typedef unsigned int u32;
-
-typedef signed long long s64;
-typedef unsigned long long u64;
+typedef __s8  s8;
+typedef __u8  u8;
+typedef __s16 s16;
+typedef __u16 u16;
+typedef __s32 s32;
+typedef __u32 u32;
+typedef __s64 s64;
+typedef __u64 u64;
 
 #define S8_C(x)  x
 #define U8_C(x)  x ## U
-- 
2.7.4

[PATCH 2/3] types: define aligned_ types based on uapi header

[Masahiro Yamada]

<uapi/linux/types.h> has the same typedefs except that it prefixes
them with double-underscore for user space.  Use them for the kernel
space typedefs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 include/linux/types.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/types.h b/include/linux/types.h
index ec13d02..be15897 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -115,9 +115,9 @@ typedef		__s64		int64_t;
 #endif
 
 /* this is a special 64bit data type that is 8-byte aligned */
-#define aligned_u64 __u64 __attribute__((aligned(8)))
-#define aligned_be64 __be64 __attribute__((aligned(8)))
-#define aligned_le64 __le64 __attribute__((aligned(8)))
+#define aligned_u64		__aligned_u64
+#define aligned_be64		__aligned_be64
+#define aligned_le64		__aligned_le64
 
 /**
  * The type used for indexing onto a disc or disc partition.
-- 
2.7.4

[PATCH 3/3] types: use fixed width types without double-underscore prefix

[Masahiro Yamada]

This header file is not exported.  It is safe to reference types
without double-underscore prefix.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 include/linux/types.h | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/linux/types.h b/include/linux/types.h
index be15897..9834e90 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -10,14 +10,14 @@
 #define DECLARE_BITMAP(name,bits) \
 	unsigned long name[BITS_TO_LONGS(bits)]
 
-typedef __u32 __kernel_dev_t;
+typedef u32 __kernel_dev_t;
 
 typedef __kernel_fd_set		fd_set;
 typedef __kernel_dev_t		dev_t;
 typedef __kernel_ino_t		ino_t;
 typedef __kernel_mode_t		mode_t;
 typedef unsigned short		umode_t;
-typedef __u32			nlink_t;
+typedef u32			nlink_t;
 typedef __kernel_off_t		off_t;
 typedef __kernel_pid_t		pid_t;
 typedef __kernel_daddr_t	daddr_t;
@@ -95,23 +95,23 @@ typedef unsigned long		ulong;
 #ifndef __BIT_TYPES_DEFINED__
 #define __BIT_TYPES_DEFINED__
 
-typedef		__u8		u_int8_t;
-typedef		__s8		int8_t;
-typedef		__u16		u_int16_t;
-typedef		__s16		int16_t;
-typedef		__u32		u_int32_t;
-typedef		__s32		int32_t;
+typedef u8			u_int8_t;
+typedef s8			int8_t;
+typedef u16			u_int16_t;
+typedef s16			int16_t;
+typedef u32			u_int32_t;
+typedef s32			int32_t;
 
 #endif /* !(__BIT_TYPES_DEFINED__) */
 
-typedef		__u8		uint8_t;
-typedef		__u16		uint16_t;
-typedef		__u32		uint32_t;
+typedef u8			uint8_t;
+typedef u16			uint16_t;
+typedef u32			uint32_t;
 
 #if defined(__GNUC__)
-typedef		__u64		uint64_t;
-typedef		__u64		u_int64_t;
-typedef		__s64		int64_t;
+typedef u64			uint64_t;
+typedef u64			u_int64_t;
+typedef s64			int64_t;
 #endif
 
 /* this is a special 64bit data type that is 8-byte aligned */
-- 
2.7.4

Re: [PATCH 3/3] types: use fixed width types without double-underscore prefix

[Andrew Morton]

On Tue, 15 May 2018 11:22:05 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote:

> This header file is not exported.  It is safe to reference types
> without double-underscore prefix.
> 

It may be safe to do this, but why is it desirable?

> index be15897..9834e90 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -10,14 +10,14 @@
>  #define DECLARE_BITMAP(name,bits) \
>  	unsigned long name[BITS_TO_LONGS(bits)]
>  
> -typedef __u32 __kernel_dev_t;
> +typedef u32 __kernel_dev_t;
>
> ...
>

Re: [PATCH 3/3] types: use fixed width types without double-underscore prefix

[Masahiro Yamada]

Hi Andrew,

2018-05-16 7:59 GMT+09:00 Andrew Morton <akpm@linux-foundation.org>:
> On Tue, 15 May 2018 11:22:05 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
>> This header file is not exported.  It is safe to reference types
>> without double-underscore prefix.
>>
>
> It may be safe to do this, but why is it desirable?


It is shorter. That's all.
If it is a noise commit, please feel free to drop it.


BTW, a large amount of kernel-space code
uses underscore-prefixed types.
I wonder if we could check it by checkpatch.pl or something...


>> index be15897..9834e90 100644
>> --- a/include/linux/types.h
>> +++ b/include/linux/types.h
>> @@ -10,14 +10,14 @@
>>  #define DECLARE_BITMAP(name,bits) \
>>       unsigned long name[BITS_TO_LONGS(bits)]
>>
>> -typedef __u32 __kernel_dev_t;
>> +typedef u32 __kernel_dev_t;
>>
>> ...
>>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/3] types: use fixed width types without double-underscore prefix

[Greg Kroah-Hartman]

On Wed, May 16, 2018 at 10:07:50AM +0900, Masahiro Yamada wrote:
> Hi Andrew,
> 
> 2018-05-16 7:59 GMT+09:00 Andrew Morton <akpm@linux-foundation.org>:
> > On Tue, 15 May 2018 11:22:05 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> >
> >> This header file is not exported.  It is safe to reference types
> >> without double-underscore prefix.
> >>
> >
> > It may be safe to do this, but why is it desirable?
> 
> 
> It is shorter. That's all.
> If it is a noise commit, please feel free to drop it.
> 
> 
> BTW, a large amount of kernel-space code
> uses underscore-prefixed types.

Sometimes it can/should do that.

> I wonder if we could check it by checkpatch.pl or something...

You do understand the difference between the two types and why/when they
are needed, right?  I don't think checkpatch.pl can determine if data is
coming from userspace or not very easily to make this a simple perl
script check :(

thanks,

greg k-h

Re: [PATCH 3/3] types: use fixed width types without double-underscore prefix

[Masahiro Yamada]

2018-05-16 15:26 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Wed, May 16, 2018 at 10:07:50AM +0900, Masahiro Yamada wrote:
>> Hi Andrew,
>>
>> 2018-05-16 7:59 GMT+09:00 Andrew Morton <akpm@linux-foundation.org>:
>> > On Tue, 15 May 2018 11:22:05 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>> >
>> >> This header file is not exported.  It is safe to reference types
>> >> without double-underscore prefix.
>> >>
>> >
>> > It may be safe to do this, but why is it desirable?
>>
>>
>> It is shorter. That's all.
>> If it is a noise commit, please feel free to drop it.
>>
>>
>> BTW, a large amount of kernel-space code
>> uses underscore-prefixed types.
>
> Sometimes it can/should do that.

I agree that UAPI headers must do that.

If you mean "it should even for non-exported code",
I have no idea why.



>> I wonder if we could check it by checkpatch.pl or something...
>
> You do understand the difference between the two types and why/when they
> are needed, right?  I don't think checkpatch.pl can determine if data is
> coming from userspace or not very easily to make this a simple perl
> script check :(


I am getting puzzled...

It sounds like you are talking about __user or __kernel.
If so, it is a matter of sparse tool
but I believe it is a different topic.


If I understand correctly,
using 'u32' is safe outside of 'include/uapi/' and
arch/$(SRCARCH)/include/uapi/

Why can't a simple script do that?

Am I missing something?



> thanks,
>
> greg k-h



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/3] types: use fixed width types without double-underscore prefix

[Greg Kroah-Hartman]

On Wed, May 16, 2018 at 03:59:01PM +0900, Masahiro Yamada wrote:
> 2018-05-16 15:26 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> > On Wed, May 16, 2018 at 10:07:50AM +0900, Masahiro Yamada wrote:
> >> Hi Andrew,
> >>
> >> 2018-05-16 7:59 GMT+09:00 Andrew Morton <akpm@linux-foundation.org>:
> >> > On Tue, 15 May 2018 11:22:05 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> >> >
> >> >> This header file is not exported.  It is safe to reference types
> >> >> without double-underscore prefix.
> >> >>
> >> >
> >> > It may be safe to do this, but why is it desirable?
> >>
> >>
> >> It is shorter. That's all.
> >> If it is a noise commit, please feel free to drop it.
> >>
> >>
> >> BTW, a large amount of kernel-space code
> >> uses underscore-prefixed types.
> >
> > Sometimes it can/should do that.
> 
> I agree that UAPI headers must do that.
> 
> If you mean "it should even for non-exported code",
> I have no idea why.
> 
> 
> 
> >> I wonder if we could check it by checkpatch.pl or something...
> >
> > You do understand the difference between the two types and why/when they
> > are needed, right?  I don't think checkpatch.pl can determine if data is
> > coming from userspace or not very easily to make this a simple perl
> > script check :(
> 
> 
> I am getting puzzled...
> 
> It sounds like you are talking about __user or __kernel.
> If so, it is a matter of sparse tool
> but I believe it is a different topic.
> 
> 
> If I understand correctly,
> using 'u32' is safe outside of 'include/uapi/' and
> arch/$(SRCARCH)/include/uapi/
> 
> Why can't a simple script do that?
> 
> Am I missing something?

I think we are talking past each other here :)

__ types are for when the variable crosses the user/kernel boundry,
that's all.  ioctl structures are one such example, as are some of these
specific userspace-facing types that you are changing here.

We have loads of ioctl structures that are _not_ in uapi/ which is a
totally different problem that I know some people are looking at fixing
up, so a checkpatch.pl rule would not be good here.

There's also places where data comes in from hardware that use the __
types, but those are usually a bit more rare.

thanks,

greg k-h