AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Bill.Fisher@lsi.com>,<Maxim.Kozlovsky@lsi.com>,<Larry.Scheer@lsi.com>,<Rendell.Fong@lsi.com>,<Brian.Stark@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	4B8C3217.1000400@lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 1 Mar 2010 13:57:24 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Fisher, Bill" <Bill.Fisher@lsi.com>
Cc: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>, "Scheer, Larry"
 <Larry.Scheer@lsi.com>, "Fong, Rendell" <Rendell.Fong@lsi.com>, "Stark,
 Brian" <Brian.Stark@lsi.com>
Subject: Re: kernel versus user level boolean definition
Message-ID: <20100301135724.1bf0ee70@ripper.onstor.net>
In-Reply-To: <4B8C3217.1000400@lsi.com>
References: <4B8C3217.1000400@lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

There's nothing new in this email, everything in here was already well
known.  boolean is discouraged for kernel use because it's about truth
value, which doesn't mean much at the kernel level.  Also, it has an
ambiguous size since many times it's not based on the gcc 'bool' type
but instead on some local-er typedef.  So size obfuscation == not good
for many kernel structures; ambiguity at the binary/disassembly debug
level; and lack of 'unknown' in gcc value set means it's not truly a
boolean anyway.

All that said, I think it will be OK to ease up on the boolean pogrom
that I started.  I fixed a bunch of these 'ints' a while back, that
will have to be enough for now, especially since it seems to upset
Max.  And we want to avoid that.

Cheers,

a

On Mon, 1 Mar 2010 14:31:03 -0700 William Fisher <bill.fisher@lsi.com>
wrote:

> Folks:
> 
> Doing a brief search, I have found that the Linux
> kernel does in deed define and use _Bool as a valid type,
> as found in linux/types.h
> 
> ==============================
> In the EEE version of the file nfx-types.h we find:
> 
> #if !defined(SSC) && !defined(__OpenBSD__) && !defined(linux) && 
> !defined(__BIT_TYPES_DEFINED__)
> 
> typedef uint32 uint32_t;
> typedef uint64 uint64_t;
> typedef uint16 uint16_t;
> typedef uint8 uint8_t;
> 
> typedef uint32 u_long;
> typedef int64      quad_t;
> typedef uint64     u_quad_t;
> 
> #include <mips/types.h>
> 
> typedef __SIZE_TYPE__ size_t;
> 
> #else
> #include <sys/types.h>
> #endif
> 
> #if (defined(NFP_TXRX) || defined(NFP_FP)) && !defined(FS_STANDALONE)
> typedef _Bool       boolean;
> #else
> typedef unsigned char       boolean;
> #endif
> 
> So for the SSC boolean is an 8-bit type
> for the others it's a _Bool, the compiler
> built in typedef.
> 
> ======================
> 
> Under the Linux kernel _Bool is defined as "bool"
> in include/linux/types.h we find:
> 
> #ifdef __KERNEL__
> typedef _Bool                   bool;
> 
> typedef __kernel_uid32_t        uid_t;
> typedef __kernel_gid32_t        gid_t;
> typedef __kernel_uid16_t        uid16_t;
> typedef __kernel_gid16_t        gid16_t;
> 
> #ifdef CONFIG_UID16
> /* This is defined by include/asm-{arch}/posix_types.h */
> typedef __kernel_old_uid_t      old_uid_t;
> typedef __kernel_old_gid_t      old_gid_t;
> #endif /* CONFIG_UID16 */
> 
> /* libc5 includes this file to define uid_t, thus uid_t can never
> change
>   * when it is included by non-kernel code
>   */
> #else
> typedef __kernel_uid_t          uid_t;
> typedef __kernel_gid_t          gid_t;
> #endif /* __KERNEL__ */
> 
> 
> Since _Bool is a compiler built in, the kernel
> DOES indeed use bool all over and it makes
> no sense to change that.
> ========================
> 
> Under /usr/mipsel-linux-gnu/include/sys/types.h
> 
> there is NO define for any boolean name variant.
> 
> Also under mips/types.h there is none.
> 
> Under the
> /usr/mipsel-linux-gnu/include directory we find:
> 
> 
> bfisher-linux: 1324>grep -i ool */types.h
> gssrpc/types.h:#define  bool_t  int
> rpc/types.h:typedef int bool_t;
> 
> These are bool_t not _Bool.
> 
> There are vaious refines for bool in selected
> portions of the kernel in some drivers but
> they are very isolated.
> 
> ------------------------
> 
> Under ../include/linux/kernel.h we find usages of
> bool in the code for various parameters as well as
> function definitions.
> 
> ===================
> 
> Hence in summary, the kernel DOES use "bool" as
> a typedef all over. It's defined to be a "_Bool"
> 
> The EEE TXRX and FP use the _Bool definition for
> everything except the SSC where it is an 8-bit
> value. Since _Bool is an 8-bit quantity
> as a compiler built-in they are consistent.
> 
> =============================
> 
> So I suggest we leave it as it was under EEE.
> 
> This is consistent with both the kernel's usage
> as well as those by the SSC.
> 
> Hence the current include/linux/onstor/nfx-types.h
> will reflect this consistent usage and the
> code should stay as it was.
> 
> Hopefully, this adds some hard usage data
> to the argument.
> 
> I agree with Max, there is not a compelling argument
> to change it since the kernel DOES use "bool" as
> defined by the compiler built-in typedef _Bool.
> 
> Let's go with the historical kernel usage and
> EEE code definitions. Andy may dislike boolean
> as a typedef but there is historical usage
> in both Linux and EEE that are consistent.
> 
> Comments?
> 
> -- Bill
> 
> 
> 
> 
> 
> 
> 
> 
