From owner-cvs-all@FreeBSD.ORG Tue Mar 28 20:27:56 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FC3416A400; Tue, 28 Mar 2006 20:27:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2B6643D48; Tue, 28 Mar 2006 20:27:55 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2SKRq4M072229; Tue, 28 Mar 2006 15:27:52 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Daniel Eischen Date: Tue, 28 Mar 2006 15:28:37 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603281528.41502.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1360/Tue Mar 28 14:21:07 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.8 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/i386/include atomic.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 20:27:56 -0000 On Tuesday 28 March 2006 15:04, Daniel Eischen wrote: > On Tue, 28 Mar 2006, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: >=20 > > John Baldwin writes: > > > s/off/on/ I trust > > > > > > Not true. The tinderbox would attest to that. Please see code such = as > > > this: [...] > > > > which uses uintptr_t, not actual pointers, to avoid warnings. In > > effect, that code is broken. > > > > Apply the attached patch, see how far a buildkernel gets... > > > > I think the proper thing to do, to cover all your bases, would be to > > define a MD atomic_*_intptr family which operated on uintptr_t, and > > define an MI atomic_*_ptr family which operates on void * based on > > that. >=20 > I would like to see that. >=20 > > > Even userland uses casts when it uses void * rather than uintptr_t for > > > the underlying type. See src/lib/libpthread/sys/lock.c or > > > src/lib/libthr/thr_umtx.h. >=20 > I didn't like having to do that in libpthread. It was confusing > to me. I'd be happy if I never had to deal with uintptr_t. Then please provide the C idiom for declaring a pointer to a volatile void pointer. volatile void ** declares a pointer to a pointer to a volatile void. This is a real issue that was causing problems with refcounting on mbuf's on sparc64 last year due to us not properly letting the compiler know what values were being invalidated. cdecl doesn't seem up to the task. And again, we already had this discussion N months ago. =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org