From gd78059@sac.sfbay.sun.com Mon Aug 10 16:35:51 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7ANZoBB012050 for ; Mon, 10 Aug 2009 16:35:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7ANZmwu022901; Tue, 11 Aug 2009 00:35:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO600J01PJQ9C00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 10 Aug 2009 16:35:50 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO600BK8PJPOB30@nwk-avmta-1.sfbay.Sun.COM>; Mon, 10 Aug 2009 16:35:49 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7ANZnXh005615; Mon, 10 Aug 2009 16:35:49 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7ANZmGf012044; Mon, 10 Aug 2009 16:35:48 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n7ANZmvT012040; Mon, 10 Aug 2009 16:35:48 -0700 (PDT) Date: Mon, 10 Aug 2009 16:35:48 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: sys/stdbool.h [PSARC/2009/429 FastTrack timeout 2009/09/17] To: PSARC-ext@sun.com Cc: roland.mainz@nrubsig.org Message-id: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3216 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: sys/stdbool.h 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 10 August, 2009 4. Technical Description I am sponsoring this fast track for Roland Mainz. The case times out in one week (8/19/2009), and minor binding is requested. -- Garrett 1. Introduction This case a new header to allow kernel code to use the C99 datatype "bool" and the associated values "true" and "false". The committment level of these interfaces is "Committed". The release binding is "minor". 2. Discussion We need to move to (and create a new which sources ) that (new [2]) kernel code can use the new C99 datatype "bool" ([1]) ? [1]="bool" differs from the traditional kernel-land "boolean_t" datatype that it is smaller (e.g. |sizeof(boolean_t)==sizeof(int)| vs. |sizeof(bool)==1|) and optionally allows the compiler to do better optimisations on this datatype (since it is allowed to assume that it only contains "true" and "false" as values instead of the full range from |INT_MIN|-|INT_MAX| for "boolean_t" (since this |enum| is treated as |int| by value-range optimisations)) and usually reduces the size of executables (see CR #6870093). [2]=Note that we do not intend do force developers to replace "boolean_t" in existing code, only allow that new code or changes (optionally) can use this C99 feature. 3. Interface table Interface | committment level -----------------------------------------------+------------------ | Commited C99 datatype "bool" | Commited C99 value "true" | Commited C99 value "false" | Commited C99 CPP symbol "__bool_true_false_are_defined" | Commited Notes: 1. precisely implements the functionality for defined in IEEE Std 1003.1-2001. 2. The ability to undefine and redefine the macros "bool", "true", and "false" is an _implementation_detail_ in the ISO C standard which may be withdrawn in a future version of the standards specifications, kernel code shall _not_ rely on this _implementation_detail_ (e.g. "#undef true", "#undef false", "#undef bool" are not allowed in kernel code as they may cause problems with future compiler versions). 4. References - Bugster CR #6870093 RFE: C99 should be visible for kernel modules - IEEE Std 1003.1-2001 - http://en.wikipedia.org/wiki/Stdbool.h - ISO C99 draft (final document is not available for free) http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf 5. Manual page differences None required. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Tue Aug 11 02:01:10 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7B919gO027980 for ; Tue, 11 Aug 2009 02:01:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7B8wa5c000089 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Aug 2009 09:59:24 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO700701FMVGX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Aug 2009 02:59:19 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO700KAIFMUCP60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Aug 2009 02:59:19 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7B8xHtd001813 for ; Tue, 11 Aug 2009 08:59:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO700D00F3W8M00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Aug 2009 09:58:55 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO700J50FLQC080@fe-emea-10.sun.com>; Tue, 11 Aug 2009 09:58:39 +0100 (BST) Date: Tue, 11 Aug 2009 09:58:30 +0100 From: Darren J Moffat Subject: Re: sys/stdbool.h [PSARC/2009/429 FastTrack timeout 2009/09/17] In-reply-to: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com Message-id: <4A8132B6.7070704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 255 Garrett D'Amore - sun microsystems wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > sys/stdbool.h +1 -- Darren J Moffat From Peter.Cudhea@sun.com Tue Aug 11 08:27:51 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BFRpjJ011844 for ; Tue, 11 Aug 2009 08:27:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BFRoPW009145 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Aug 2009 08:27:51 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO700003XMFPU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 11 Aug 2009 09:27:51 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO7009TIXMEKBA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 11 Aug 2009 09:27:50 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7BFRoM8016205 for ; Tue, 11 Aug 2009 15:27:50 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KO700600XCWX200@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 11 Aug 2009 09:27:50 -0600 (MDT) Received: from [129.148.168.14] ([unknown] [129.148.168.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KO70014WXMDUW90@mail-amer.sun.com>; Tue, 11 Aug 2009 09:27:50 -0600 (MDT) Date: Tue, 11 Aug 2009 11:26:42 -0400 From: Peter Cudhea Subject: Re: sys/stdbool.h [PSARC/2009/429 FastTrack timeout 2009/09/17] In-reply-to: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> Sender: Peter.Cudhea@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, roland.mainz@nrubsig.org Reply-to: Peter.Cudhea@sun.com Message-id: <4A818DB2.7060208@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090720) Status: RO Content-Length: 4246 It would be useful to take a definitive stand on whether or not operations on two adjacent bool values are atomic with respect to one another. E.g. back in the days of the DEC Alpha, there existed no instructions that could modify the value of one bool in a word without potentially interfering in other uses of a differnt bool in the same word. That consideration does not apply to either of the current Solaris platforms. But are we introducing a constraint that Solaris could never be ported to such a platform? Or are we introducing a constraint that any values that should be updatable atomically should be stored in a boolean_t and not in a bool? Or does the compiler guarantee to allocate bools on word boundaries in platforms such as this? Either way, we should spell it out. Peter On 08/10/09 19:35, Garrett D'Amore - sun microsystems wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > sys/stdbool.h > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 10 August, 2009 > 4. Technical Description > I am sponsoring this fast track for Roland Mainz. The case times out in one > week (8/19/2009), and minor binding is requested. > > -- Garrett > > 1. Introduction > > This case a new header to allow kernel code > to use the C99 datatype "bool" and the associated values > "true" and "false". > > The committment level of these interfaces is "Committed". > > The release binding is "minor". > > 2. Discussion > > We need to move to (and create a new > which sources ) that (new [2]) kernel > code can use the new C99 datatype "bool" ([1]) ? > > [1]="bool" differs from the traditional kernel-land "boolean_t" > datatype that it is smaller (e.g. |sizeof(boolean_t)==sizeof(int)| > vs. |sizeof(bool)==1|) and optionally allows the compiler to do > better optimisations on this datatype (since it is allowed to > assume that it only contains "true" and "false" as values instead > of the full range from |INT_MIN|-|INT_MAX| for "boolean_t" (since > this |enum| is treated as |int| by value-range optimisations)) > and usually reduces the size of executables (see CR #6870093). > > [2]=Note that we do not intend do force developers to replace > "boolean_t" in existing code, only allow that new code or changes > (optionally) can use this C99 feature. > > 3. Interface table > > Interface | committment level > -----------------------------------------------+------------------ > | Commited > C99 datatype "bool" | Commited > C99 value "true" | Commited > C99 value "false" | Commited > C99 CPP symbol "__bool_true_false_are_defined" | Commited > > Notes: > 1. precisely implements the functionality for > defined in IEEE Std 1003.1-2001. > 2. The ability to undefine and redefine the macros "bool", > "true", and "false" is an _implementation_detail_ in the ISO C > standard which may be withdrawn in a future version of the > standards specifications, kernel code shall _not_ rely on this > _implementation_detail_ (e.g. "#undef true", "#undef false", > "#undef bool" are not allowed in kernel code as they may cause > problems with future compiler versions). > > 4. References > - Bugster CR #6870093 RFE: C99 should be visible for > kernel modules > - IEEE Std 1003.1-2001 > - http://en.wikipedia.org/wiki/Stdbool.h > - ISO C99 draft (final document is not available for free) > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf > > 5. Manual page differences > > None required. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From gdamore@sun.com Tue Aug 11 08:39:54 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BFdrPx012109 for ; Tue, 11 Aug 2009 08:39:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7BFdiUw024004 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Aug 2009 16:39:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO700983Y6FVH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 11 Aug 2009 08:39:51 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO7000C3Y6E15B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 11 Aug 2009 08:39:50 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BFdobx008468 for ; Tue, 11 Aug 2009 08:39:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO700D00Y51IB00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 11 Aug 2009 08:39:50 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO700721Y6DH5A0@fe-sfbay-09.sun.com>; Tue, 11 Aug 2009 08:39:49 -0700 (PDT) Date: Tue, 11 Aug 2009 08:39:48 -0700 From: "Garrett D'Amore" Subject: Re: sys/stdbool.h [PSARC/2009/429 FastTrack timeout 2009/09/17] In-reply-to: <4A818DB2.7060208@Sun.COM> Sender: Garrett.Damore@sun.com To: Peter.Cudhea@sun.com Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, roland.mainz@nrubsig.org Message-id: <4A8190C4.5070302@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> <4A818DB2.7060208@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 5631 Peter Cudhea wrote: > It would be useful to take a definitive stand on whether or not > operations on two adjacent bool values are atomic with respect to one > another. E.g. back in the days of the DEC Alpha, there existed no > instructions that could modify the value of one bool in a word without > potentially interfering in other uses of a differnt bool in the same > word. That consideration does not apply to either of the current > Solaris platforms. But are we introducing a constraint that Solaris > could never be ported to such a platform? Or are we introducing a > constraint that any values that should be updatable atomically should > be stored in a boolean_t and not in a bool? Or does the compiler > guarantee to allocate bools on word boundaries in platforms such as > this? Either way, we should spell it out. I would suggest that in situations where this matters, there are a couple of options: 1) use locking primitives to guard an associated group of booleans. 2) find out what C99 says about this (if anything) 3) if you're really that concerned, such as in kernel space, use boolean_t. I raised some of these concerns in private review with Roland before submitting the case. Personally, I have reservations about using C99 bool in places where atomicity is a requirement, or in public headers where it might force C99, or in structures where strict packing is required. That said... For uses where the value appears on the stack or as a function return, or is a member of a structure that is protected by other schemes (such as the entire structure only being accessed under management of a lock), I think the C99 bool type might have significant benefits. Roland has made the case to me that use of this can result in substantial improvements in code size and performance, based on tests he's performed with the ksh93 and AST code. (For example, on some platforms the compiler can just directly test a status bit in a machine word without performing a subtraction to compare against zero.) -- Garrett > > Peter > > On 08/10/09 19:35, Garrett D'Amore - sun microsystems wrote: >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> sys/stdbool.h >> 1.2. Name of Document Author/Supplier: >> Author: Garrett D'Amore >> 1.3 Date of This Document: >> 10 August, 2009 >> 4. Technical Description >> I am sponsoring this fast track for Roland Mainz. The case times out >> in one >> week (8/19/2009), and minor binding is requested. >> >> -- Garrett >> >> 1. Introduction >> >> This case a new header to allow kernel code >> to use the C99 datatype "bool" and the associated values >> "true" and "false". >> >> The committment level of these interfaces is "Committed". >> >> The release binding is "minor". >> >> 2. Discussion >> >> We need to move to (and create a new >> which sources ) that (new [2]) kernel >> code can use the new C99 datatype "bool" ([1]) ? >> >> [1]="bool" differs from the traditional kernel-land "boolean_t" >> datatype that it is smaller (e.g. |sizeof(boolean_t)==sizeof(int)| >> vs. |sizeof(bool)==1|) and optionally allows the compiler to do >> better optimisations on this datatype (since it is allowed to >> assume that it only contains "true" and "false" as values instead >> of the full range from |INT_MIN|-|INT_MAX| for "boolean_t" (since >> this |enum| is treated as |int| by value-range optimisations)) >> and usually reduces the size of executables (see CR #6870093). >> >> [2]=Note that we do not intend do force developers to replace >> "boolean_t" in existing code, only allow that new code or changes >> (optionally) can use this C99 feature. >> >> 3. Interface table >> >> Interface | committment level >> -----------------------------------------------+------------------ >> | Commited >> C99 datatype "bool" | Commited >> C99 value "true" | Commited >> C99 value "false" | Commited >> C99 CPP symbol "__bool_true_false_are_defined" | Commited >> >> Notes: >> 1. precisely implements the functionality for >> defined in IEEE Std 1003.1-2001. >> 2. The ability to undefine and redefine the macros "bool", >> "true", and "false" is an _implementation_detail_ in the ISO C >> standard which may be withdrawn in a future version of the >> standards specifications, kernel code shall _not_ rely on this >> _implementation_detail_ (e.g. "#undef true", "#undef false", >> "#undef bool" are not allowed in kernel code as they may cause >> problems with future compiler versions). >> >> 4. References >> - Bugster CR #6870093 RFE: C99 should be visible for >> kernel modules >> - IEEE Std 1003.1-2001 >> - http://en.wikipedia.org/wiki/Stdbool.h >> - ISO C99 draft (final document is not available for free) >> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf >> >> 5. Manual page differences >> >> None required. >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> From roland.mainz@nrubsig.org Tue Aug 11 19:45:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7C2jeP9007254 for ; Tue, 11 Aug 2009 19:45:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7C2jV7T015074; Wed, 12 Aug 2009 03:45:38 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800303T010U00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 20:45:37 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO8001NBT007P00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 20:45:36 -0600 (MDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7C2Zqfu002015; Wed, 12 Aug 2009 02:45:36 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-2375942; Wed, 12 Aug 2009 02:45:34 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-51130256; Wed, 12 Aug 2009 02:45:29 +0000 (Z) Received: from mail-in-07.arcor-online.net ([151.189.21.47] [151.189.21.47]) by relay4i.sun.com with ESMTP id BT-MMP-2276707; Wed, 12 Aug 2009 02:45:29 +0000 (Z) Received: from mail-in-18-z2.arcor-online.net (mail-in-18-z2.arcor-online.net [151.189.8.35]) by mx.arcor.de (Postfix) with ESMTP id 553643CA247; Wed, 12 Aug 2009 04:45:28 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-18-z2.arcor-online.net (Postfix) with ESMTP id 39F705107C6; Wed, 12 Aug 2009 04:45:28 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-188-097-013-022.pools.arcor-ip.net [188.97.13.22]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id D943D1B37A2; Wed, 12 Aug 2009 04:45:26 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n7C2jNV6001095; Wed, 12 Aug 2009 04:45:23 +0200 (CEST) Date: Wed, 12 Aug 2009 04:45:23 +0200 From: Roland Mainz Subject: Re: sys/stdbool.h [PSARC/2009/429 FastTrack timeout 2009/09/17] Sender: gisburn@jupiterb48.nrubsig.org To: Peter.Cudhea@sun.com Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4A822CC3.6776AFDF@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net D943D1B37A2 X-Antispam: No, score=-1.1/5.0, scanned in 3.243sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> <4A818DB2.7060208@Sun.COM> Status: RO Content-Length: 3986 Peter Cudhea wrote: > On 08/10/09 19:35, Garrett D'Amore - sun microsystems wrote: > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > > This information is Copyright 2009 Sun Microsystems > > 1. Introduction > > 1.1. Project/Component Working Name: > > sys/stdbool.h > > 1.2. Name of Document Author/Supplier: > > Author: Garrett D'Amore > > 1.3 Date of This Document: > > 10 August, 2009 > > 4. Technical Description > > I am sponsoring this fast track for Roland Mainz. The case times out in one > > week (8/19/2009), and minor binding is requested. [snip] > > 3. Interface table > > > > Interface | committment level > > -----------------------------------------------+------------------ > > | Commited > > C99 datatype "bool" | Commited > > C99 value "true" | Commited > > C99 value "false" | Commited > > C99 CPP symbol "__bool_true_false_are_defined" | Commited > > > > Notes: > > 1. precisely implements the functionality for > > defined in IEEE Std 1003.1-2001. > > 2. The ability to undefine and redefine the macros "bool", > > "true", and "false" is an _implementation_detail_ in the ISO C > > standard which may be withdrawn in a future version of the > > standards specifications, kernel code shall _not_ rely on this > > _implementation_detail_ (e.g. "#undef true", "#undef false", > > "#undef bool" are not allowed in kernel code as they may cause > > problems with future compiler versions). > > > > 4. References > > - Bugster CR #6870093 RFE: C99 should be visible for > > kernel modules > > - IEEE Std 1003.1-2001 > > - http://en.wikipedia.org/wiki/Stdbool.h > > - ISO C99 draft (final document is not available for free) > > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf [snip] > > It would be useful to take a definitive stand on whether or not > operations on two adjacent bool values are atomic with respect to one > another. E.g. back in the days of the DEC Alpha, there existed no > instructions that could modify the value of one bool in a word without > potentially interfering in other uses of a differnt bool in the same > word. AFAIK Solaris supports |atomic_swap_uchar()| for userland applications - since |bool| is a byte ([1]) on Solaris this may be used for atomic operations... [1]=Assuming the compiler cannot "reduce" it somehow further, e.g. if the variable is "standalone" (e.g. not part of a struct, not accessed via pointer etc.) the compiler may tweak it as it likes it (the only other factor is the amount of states the variable may hold - but that's exactly defined to be two ({ |true, |false| }) and therefore eliminates that issue for the compiler). > That consideration does not apply to either of the current > Solaris platforms. But are we introducing a constraint that Solaris > could never be ported to such a platform? Or are we introducing a > constraint that any values that should be updatable atomically should be > stored in a boolean_t and not in a bool? Or does the compiler > guarantee to allocate bools on word boundaries in platforms such as > this? Either way, we should spell it out. Erm... this case is only to make the C99 header |stdbool.h> (and the associated C99 datatype |bool|) available for kernel code (which IMO should've been done at the time when C99 support was added to Solaris (e.g. this case is basically "janitor work")) and _not_ to interpret more on top of it, e.g. we only gurantee what the ISO C standard says about |bool| and nothing beyond that. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz@nrubsig.org Tue Aug 11 19:58:21 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7C2wLp3007947 for ; Tue, 11 Aug 2009 19:58:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7C2wKnr006036; Tue, 11 Aug 2009 19:58:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800I05TL7MC00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Aug 2009 19:58:19 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800B42TL6R640@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Aug 2009 19:58:18 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7C2snbS003220; Wed, 12 Aug 2009 02:58:18 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay41i.sun.com with ESMTP id BT-MMP-2376458; Wed, 12 Aug 2009 02:58:18 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-53450818; Wed, 12 Aug 2009 02:58:17 +0000 (Z) Received: from mail-in-04.arcor-online.net ([151.189.21.44] [151.189.21.44]) by relay4i.sun.com with ESMTP id BT-MMP-2301108; Wed, 12 Aug 2009 02:58:12 +0000 (Z) Received: from mail-in-18-z2.arcor-online.net (mail-in-18-z2.arcor-online.net [151.189.8.35]) by mx.arcor.de (Postfix) with ESMTP id 8AA7D33A755; Wed, 12 Aug 2009 04:58:11 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-18-z2.arcor-online.net (Postfix) with ESMTP id 7A552510573; Wed, 12 Aug 2009 04:58:11 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-188-097-013-022.pools.arcor-ip.net [188.97.13.22]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id 46C921B378D; Wed, 12 Aug 2009 04:58:10 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n7C2w7NJ001100; Wed, 12 Aug 2009 04:58:07 +0200 (CEST) Date: Wed, 12 Aug 2009 04:58:07 +0200 From: Roland Mainz Subject: Re: sys/stdbool.h [PSARC/2009/429 FastTrack timeout 2009/09/17] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Peter.Cudhea@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4A822FBF.15F58760@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net 46C921B378D X-Antispam: No, score=0.0/5.0, scanned in 0.343sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> <4A818DB2.7060208@Sun.COM> <4A8190C4.5070302@sun.com> Status: RO Content-Length: 2138 Garrett D'Amore wrote: > Peter Cudhea wrote: > > It would be useful to take a definitive stand on whether or not > > operations on two adjacent bool values are atomic with respect to one > > another. E.g. back in the days of the DEC Alpha, there existed no > > instructions that could modify the value of one bool in a word without > > potentially interfering in other uses of a differnt bool in the same > > word. That consideration does not apply to either of the current > > Solaris platforms. But are we introducing a constraint that Solaris > > could never be ported to such a platform? Or are we introducing a > > constraint that any values that should be updatable atomically should > > be stored in a boolean_t and not in a bool? Or does the compiler > > guarantee to allocate bools on word boundaries in platforms such as > > this? Either way, we should spell it out. > > I would suggest that in situations where this matters, there are a > couple of options: > > 1) use locking primitives to guard an associated group of booleans. > 2) find out what C99 says about this (if anything) > 3) if you're really that concerned, such as in kernel space, use boolean_t. > > I raised some of these concerns in private review with Roland before > submitting the case. Personally, I have reservations about using C99 > bool in places where atomicity is a requirement, What about adding an |atomic_swap_bool()| (e.g. an alias for |atomic_swap_uchar()|) to ? > or in public headers > where it might force C99, or in structures where strict packing is required. What do you mean with "strict packaging" in this case ? |bool| will behave like the platform's smallest datatype (e.g. |char| (one byte on SPARC+x86)) within a struct and therefore consume a lot less than |boolean_t| (which may result in less data cache usage since |boolean_t| is AFAIK an |enum| which consumes the space of an |int| (four bytes on SPARC+x86)) ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore@sun.com Tue Aug 11 22:47:47 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7C5lkNL013955 for ; Tue, 11 Aug 2009 22:47:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7C5lcJI018445 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Aug 2009 06:47:46 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO9008051FKJX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Aug 2009 22:47:44 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO900BIW1FJR4A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Aug 2009 22:47:43 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7C5lhna013846 for ; Tue, 11 Aug 2009 22:47:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO900B0015QCA00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Aug 2009 22:47:43 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO900GN71FIFE60@fe-sfbay-09.sun.com>; Tue, 11 Aug 2009 22:47:43 -0700 (PDT) Date: Tue, 11 Aug 2009 22:47:42 -0700 From: "Garrett D'Amore" Subject: Re: sys/stdbool.h [PSARC/2009/429 FastTrack timeout 2009/09/17] In-reply-to: <4A822FBF.15F58760@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Peter.Cudhea@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4A82577E.5020608@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908102335.n7ANZmvT012040@sac.sfbay.sun.com> <4A818DB2.7060208@Sun.COM> <4A8190C4.5070302@sun.com> <4A822FBF.15F58760@nrubsig.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2556 Roland Mainz wrote: > Garrett D'Amore wrote: > >> Peter Cudhea wrote: >> >>> It would be useful to take a definitive stand on whether or not >>> operations on two adjacent bool values are atomic with respect to one >>> another. E.g. back in the days of the DEC Alpha, there existed no >>> instructions that could modify the value of one bool in a word without >>> potentially interfering in other uses of a differnt bool in the same >>> word. That consideration does not apply to either of the current >>> Solaris platforms. But are we introducing a constraint that Solaris >>> could never be ported to such a platform? Or are we introducing a >>> constraint that any values that should be updatable atomically should >>> be stored in a boolean_t and not in a bool? Or does the compiler >>> guarantee to allocate bools on word boundaries in platforms such as >>> this? Either way, we should spell it out. >>> >> I would suggest that in situations where this matters, there are a >> couple of options: >> >> 1) use locking primitives to guard an associated group of booleans. >> 2) find out what C99 says about this (if anything) >> 3) if you're really that concerned, such as in kernel space, use boolean_t. >> >> I raised some of these concerns in private review with Roland before >> submitting the case. Personally, I have reservations about using C99 >> bool in places where atomicity is a requirement, >> > > What about adding an |atomic_swap_bool()| (e.g. an alias for > |atomic_swap_uchar()|) to ? > Not a bad idea -- if the compiler is guaranteed to ensure that booleans fit in a single word. The concern is that if the boolean value is stored as a component of a larger machine word, that there could then be atomicity issues. I don't think we need to do anything as part of this case though. > >> or in public headers >> where it might force C99, or in structures where strict packing is required. >> > > What do you mean with "strict packaging" in this case ? |bool| will > behave like the platform's smallest datatype (e.g. |char| (one byte on > SPARC+x86)) within a struct and therefore consume a lot less than > |boolean_t| (which may result in less data cache usage since |boolean_t| > is AFAIK an |enum| which consumes the space of an |int| (four bytes on > SPARC+x86)) ... > I mean relying on this in a structure that is meant to be very exact, such as a structure representing on-disk, on-network, or physical device structures. - Garrett > ---- > > Bye, > Roland > > From gdamore@sun.com Wed Aug 12 10:21:54 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CHLrJp011784 for ; Wed, 12 Aug 2009 10:21:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7CHLkJh017455 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Aug 2009 18:21:52 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO900627XKGFK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 11:21:52 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO9002DVXKFF930@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 11:21:51 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7CHLpEW007799 for ; Wed, 12 Aug 2009 10:21:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KO900M00WN4QT00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 10:21:51 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KO900JTXXJWQMG0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 10:21:32 -0700 (PDT) Date: Wed, 12 Aug 2009 10:21:32 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/429 sys/stdbool.h Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <4A82FA1C.6000901@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 55 This case was approved at PSARC today. -- Garrett