From: walter harms <WHarms@bfs.de>
To: Joe Perches <joe@perches.com>
Cc: e1000-devel@lists.sourceforge.net,
xfs-masters <xfs-masters@oss.sgi.com>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [E1000-devel] [PATCH] drivers/net: convert & to &&
Date: Mon, 10 Mar 2008 12:20:21 +0000 [thread overview]
Message-ID: <47D52785.80907@bfs.de> (raw)
In-Reply-To: <1204914033.5541.74.camel@localhost>
Joe Perches wrote:
> On Thu, 2008-03-06 at 10:07 -0800, Kok, Auke wrote:
>> (which, BTW also could use the uint32_t -> u32 (etc) changes... while you're at it)
>
> I think this does what you want:
>
> for size in "8" "16" "32" "64" ; do \
> sed -r -i -e 's/\bu_{0,1}int'$size'_t\b/u'$size'/g' \
> $(grep -rPlw --include=*.[ch] 'u_{0,1}int'$size'_t' drivers/net/e1000 drivers/net/ixgb); done
>
> But why? boolean_t is used by 3 subsystems with local typedefs.
> These others are much more frequently used by kernel source.
>
> $ grep -rPlw --include=*.[ch] "u{0,1}_{0,1}int(8|16|32|64)_t" * | wc -l
> 876
>
> include/linux/types.h has typedefs for these but not boolean_t
>
> include/linux/types.h:typedef __u8 u_int8_t;
> include/linux/types.h:typedef __s8 int8_t;
> include/linux/types.h:typedef __u16 u_int16_t;
> include/linux/types.h:typedef __s16 int16_t;
> include/linux/types.h:typedef __u32 u_int32_t;
> include/linux/types.h:typedef __s32 int32_t;
> include/linux/types.h:typedef __u8 uint8_t;
> include/linux/types.h:typedef __u16 uint16_t;
> include/linux/types.h:typedef __u32 uint32_t;
> include/linux/types.h:typedef __u64 uint64_t;
> include/linux/types.h:typedef __u64 u_int64_t;
> include/linux/types.h:typedef __s64 int64_t;
>
Why not the other way around ?
inttypes.h is C99 and defines int16_t (or uint16_t). i do not see any reason
not to use them or any other type (like __u8) that does actually the same.
In that case we do not need different type names for userspace/kernelspace, or is there an other name
for int ? in that case we can remove the whole heap of typedef's.
re,
wh
WARNING: multiple messages have this Message-ID (diff)
From: walter harms <WHarms@bfs.de>
To: Joe Perches <joe@perches.com>
Cc: e1000-devel@lists.sourceforge.net,
xfs-masters <xfs-masters@oss.sgi.com>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [E1000-devel] [PATCH] drivers/net: convert & to &&
Date: Mon, 10 Mar 2008 13:20:21 +0100 [thread overview]
Message-ID: <47D52785.80907@bfs.de> (raw)
In-Reply-To: <1204914033.5541.74.camel@localhost>
Joe Perches wrote:
> On Thu, 2008-03-06 at 10:07 -0800, Kok, Auke wrote:
>> (which, BTW also could use the uint32_t -> u32 (etc) changes... while you're at it)
>
> I think this does what you want:
>
> for size in "8" "16" "32" "64" ; do \
> sed -r -i -e 's/\bu_{0,1}int'$size'_t\b/u'$size'/g' \
> $(grep -rPlw --include=*.[ch] 'u_{0,1}int'$size'_t' drivers/net/e1000 drivers/net/ixgb); done
>
> But why? boolean_t is used by 3 subsystems with local typedefs.
> These others are much more frequently used by kernel source.
>
> $ grep -rPlw --include=*.[ch] "u{0,1}_{0,1}int(8|16|32|64)_t" * | wc -l
> 876
>
> include/linux/types.h has typedefs for these but not boolean_t
>
> include/linux/types.h:typedef __u8 u_int8_t;
> include/linux/types.h:typedef __s8 int8_t;
> include/linux/types.h:typedef __u16 u_int16_t;
> include/linux/types.h:typedef __s16 int16_t;
> include/linux/types.h:typedef __u32 u_int32_t;
> include/linux/types.h:typedef __s32 int32_t;
> include/linux/types.h:typedef __u8 uint8_t;
> include/linux/types.h:typedef __u16 uint16_t;
> include/linux/types.h:typedef __u32 uint32_t;
> include/linux/types.h:typedef __u64 uint64_t;
> include/linux/types.h:typedef __u64 u_int64_t;
> include/linux/types.h:typedef __s64 int64_t;
>
Why not the other way around ?
inttypes.h is C99 and defines int16_t (or uint16_t). i do not see any reason
not to use them or any other type (like __u8) that does actually the same.
In that case we do not need different type names for userspace/kernelspace, or is there an other name
for int ? in that case we can remove the whole heap of typedef's.
re,
wh
next prev parent reply other threads:[~2008-03-10 12:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-06 17:41 [PATCH] drivers/net: convert & to && Julia Lawall
2008-03-06 17:41 ` Julia Lawall
2008-03-06 17:59 ` Joe Perches
2008-03-06 17:59 ` Joe Perches
2008-03-06 18:07 ` [E1000-devel] " Kok, Auke
2008-03-06 18:07 ` Kok, Auke
2008-03-07 1:22 ` [PATCH] drivers/net/e1000 - Convert boolean_t to bool Joe Perches
2008-03-07 1:22 ` Joe Perches
2008-03-07 1:24 ` [PATCH] drivers/net/ixgb - convert " Joe Perches
2008-03-07 1:24 ` Joe Perches
2008-03-07 17:14 ` Kok, Auke
2008-03-07 17:14 ` Kok, Auke
2008-03-07 18:20 ` [E1000-devel] [PATCH] drivers/net: convert & to && Joe Perches
2008-03-07 18:20 ` Joe Perches
2008-03-07 18:38 ` Kok, Auke
2008-03-07 18:38 ` Kok, Auke
2008-03-10 12:20 ` walter harms [this message]
2008-03-10 12:20 ` walter harms
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47D52785.80907@bfs.de \
--to=wharms@bfs.de \
--cc=e1000-devel@lists.sourceforge.net \
--cc=joe@perches.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xfs-masters@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.