Date: Thu, 12 May 2011 14:32:43 -0700 From: mdf@FreeBSD.org 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: <BANLkTi=hB=ytsGFD8NbG7q56qTQJjroPHg@mail.gmail.com> 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, May 12, 2011 at 2:12 PM, Attilio Rao <attilio@freebsd.org> wrote: > 2011/5/12 Artem Belevich <art@freebsd.org>: >> On Thu, May 12, 2011 at 10:05 PM, Attilio Rao <attilio@freebsd.org> wrot= e: >>> I spoke in person with Artem and in the end I just decided to make the >>> smallest possible subset of changes to fix the _long on 32 bits and >>> then "completed" (as some of them already exist today) the macro >>> converting the arguments to u_int stuff: >>> http://www.freebsd.org/~attilio/largeSMP/mips-atomic2.diff >> >> Attilio, >> >> Let's get back for a second to the original issue you had that propted >> you to do atomic ops changes. >> If I understand you correctly, your code was passing cpuset_t* as an >> argument to atomic_something_long and that caused compiler to complain >> that cpuset_t* is not uint32_t*. >> >> 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 =A0cpuset_t, it does atomic of members of > cpuset_t which are actually long. Isn't this an argument for making it an array of u_int, even though it's marginally pessimal on amd64 and other 64-bit arches? There is guaranteed support for a int-sized (or perhaps 32-bit sized) atomic op. Cheers, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=hB=ytsGFD8NbG7q56qTQJjroPHg>