Date: Fri, 13 May 2011 22:39:15 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Attilio Rao <attilio@freebsd.org> Cc: src-committers@freebsd.org, Artem Belevich <art@freebsd.org>, Oleksandr Tymoshenko <gonzo@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-projects@freebsd.org, Warner Losh <imp@freebsd.org> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <20110513221936.X1161@besplex.bde.org> In-Reply-To: <BANLkTikj%2Bszgd%2BptzD6y%2BofPs%2B8bR7Z8ew@mail.gmail.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> <BANLkTi=e7GtBM-PTq9yJHSLRoaOWh62AeA@mail.gmail.com> <BANLkTiktwEvRktZrGOqKKB2iSB99a3Jw=g@mail.gmail.com> <BANLkTik17r-XampEdO%2BsQ7aMOL_SDyhG=g@mail.gmail.com> <BANLkTinaWDcaiZiB3G5Szoaho1jVSeniMA@mail.gmail.com> <BANLkTimj3ohmvACmvcPa3yrdsUj=4D2V3Q@mail.gmail.com> <BANLkTikSgEXZz8vjj7kuyeWQE_oKqzB8ug@mail.gmail.com> <BANLkTinHGpL5tC3-5jOPUq6bJ2Ks7j_Dww@mail.gmail.com> <BANLkTi=DOD9p-YUMm33D5ZShTjS_Q1hEvg@mail.gmail.com> <BANLkTikj%2Bszgd%2BptzD6y%2BofPs%2B8bR7Z8ew@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 May 2011, Attilio Rao wrote:
> 2011/5/12 Artem Belevich <art@freebsd.org>:
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110513221936.X1161>