From owner-svn-src-projects@FreeBSD.ORG Fri May 13 12:39:20 2011 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49805106564A; Fri, 13 May 2011 12:39:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id D0DE98FC0C; Fri, 13 May 2011 12:39:19 +0000 (UTC) Received: from c122-106-158-76.carlnfd1.nsw.optusnet.com.au (c122-106-158-76.carlnfd1.nsw.optusnet.com.au [122.106.158.76]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p4DCdFVj003634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 22:39:17 +1000 Date: Fri, 13 May 2011 22:39:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Attilio Rao In-Reply-To: Message-ID: <20110513221936.X1161@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, Artem Belevich , Oleksandr Tymoshenko , Bruce Evans , svn-src-projects@freebsd.org, Warner Losh Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 12:39:20 -0000 On Thu, 12 May 2011, Attilio Rao wrote: > 2011/5/12 Artem Belevich : >> Could you post definition of cpuset_t ? >> >> It's possible that compiler was actually correct. For instance, >> compiler would be right to complain if cpuset_t is a packed structure, >> even if that structure is made of a single uint32_t field. > > It doesn't do the atomic of cpuset_t, it does atomic of members of > cpuset_t which are actually long. > For example: > #define CPU_OR_ATOMIC(d, s) do { \ > __size_t __i; \ > for (__i = 0; __i < _NCPUWORDS; __i++) \ > atomic_set_long(&(d)->__bits[__i], \ > (s)->__bits[__i]); \ > } while (0) BTW, how can any code like this (operating on an array) be atomic enough? >> The downside of this patch is that it typecasts everything. Along with >> potentially false positive warnings it also would force compiler to >> ignore real errors in the code. I'd prefer to see typecast at the >> caller level on as-needed basis. *If* it's needed, that is. Even that >> is not pretty either, especially if there are many places like that. > > I really think that this is what it is intended since the beginning. > If you look at the current code, it already does, likely for the > functions actually used in the kernel. The others may be just unused. Maybe for the mips version, but not casting anything was intended from the beginning for the i386 version. Complete type safety without any casts is not very hard if callers are careful to only use atomic ops on supported types. Bruce