From owner-svn-src-head@freebsd.org Tue May 3 17:58:45 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 781EFB2CF13; Tue, 3 May 2016 17:58:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAE51A3A; Tue, 3 May 2016 17:58:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-149-109.carlnfd1.nsw.optusnet.com.au (c122-106-149-109.carlnfd1.nsw.optusnet.com.au [122.106.149.109]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id C01B41A1B20; Wed, 4 May 2016 03:58:41 +1000 (AEST) Date: Wed, 4 May 2016 03:58:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin cc: Bruce Evans , Pedro Giffuni , "Ngie Cooper (yaneurabeya)" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r298933 - in head: share/man/man9 sys/amd64/include sys/dev/acpica sys/dev/drm2 sys/dev/drm2/i915 sys/kern sys/sys sys/x86/acpica sys/x86/x86 In-Reply-To: <8989101.JIAk4LJusf@ralph.baldwin.cx> Message-ID: <20160504031930.A3395@besplex.bde.org> References: <201605021800.u42I0cjK084243@repo.freebsd.org> <20160503152502.A939@besplex.bde.org> <8989101.JIAk4LJusf@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=EfU1O6SC c=1 sm=1 tr=0 a=R/f3m204ZbWUO/0rwPSMPw==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=yQTNAvRlwjzvZyhg9ksA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:58:45 -0000 On Tue, 3 May 2016, John Baldwin wrote: > On Tuesday, May 03, 2016 03:52:56 PM Bruce Evans wrote: >> On Mon, 2 May 2016, Pedro Giffuni wrote: >... >>> TBH, I thought so too, but I avoided applying such changes to headers, >>> and I haven't touched _bitset.h, >> >> _foo.h headers cannot use howmany() due to namespace pollution. >> >> _bitset.h was already broken, unless it is supposed to be kernel-only -- >> it uses howmany(). It is kernel-only according to its documention -- >> bitset is only documented in kernel manpages (in a single unreadable one >> than is linked ad nauseum). > > cpuset.h is used in userland for cpuset_getaffinity(2), etc. > >> It is otherwise fairly clean. It defines the symbols BITSET_DEFINE, >> BITSET_T_INITIALIZER, and BITSET_SET in the application namespace >> This is not completely clean for a _foo.h header. All other BITSET* >> macros are already in bitset.h I think only BITSET_DEFINE should be >> in _bitset.h (for use declarations in other headers). >> >> select.h avoids this problem by defining its own howmany() macro. This >> seems to be correct except for the bogus ifdef around the private macro. >> This ifdef is a little more than a style bug (verboseness) -- it breaks >> detection of other definitions that might be different. Lexical >> differences wouldn't matter, but it is easier to never have them. >> >> Old versions of select polluted . The select macros just >> used howmany(). howmany() was in too. > > I would be happy to fix _bitset.h and _cpuset.h to not need sys/param.h. > However, they also use NBBY which is defined in sys/param.h. _sigset.h > gets around this because it uses an array of uint32_t and hardcodes a > shift count of 5 in _SIG_WORD() and a mask of 31 in _SIG_BIT(). If you > think it is fine to hardcode '8' instead of 'NBBY' I'll do that. Hmm, > sys/select.h hardcodes '8' for _NFDBITS, so I guess that is fine. NBBY can be cleaned up too. I rather like it, but it is bogus in C90 since it is spelled CHAR_BIT there, and it is now more bogus in POSIX since POSIX started specifying 8-bit bytes in 2001. Thus 8 is the correct spelling of it in the implementation where you don't want to expose a macro that makes it clearer what this magic 8 is. BTW, I don't like select's and bitset's use of longs. Using unsigned for select is a historical mistake. Bitset apparently copied select except it unimproved to signed long. Bitstring uses unsigned char with no optimizations. Sigset uses uint32_t with no obvious optimizations, but compilers do a good job with with it due to its fixed size. I doubt that the manual optimization of using a wider size is important. Bruce