| Message ID | 1526350925-14922-3-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] int-ll64.h: define u{8,16,32,64} and s{8,16,32,64} based on uapi header | expand |
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; > > ... >
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
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
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
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
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 */
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(-) -- 2.7.4