Date: Thu, 17 Jun 2010 14:32:46 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-mips@freebsd.org Subject: Re: Merging 64 bit changes to -HEAD - part 2 Message-ID: <AANLkTinkTYuPjSNTTZxzU7iHWi4eXqQSyiUkNFRkP_FF@mail.gmail.com> In-Reply-To: <20100617.110504.200754750200158040.imp@bsdimp.com> References: <20100617.100235.195066307596264499.imp@bsdimp.com> <AANLkTimkF47RlysFOrma0YhWNDw2w5Lcp9SB1bBoPuxW@mail.gmail.com> <4B66E1A4-E2A5-471F-9FA4-38B506797272@lakerest.net> <20100617.110504.200754750200158040.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Picking the most recent message to reply to ] On Thu, Jun 17, 2010 at 10:05, M. Warner Losh <imp@bsdimp.com> wrote: > It was also a name-space collision, so we were using PG_x instead of > PG_y in the PTE code due to the overlap. =A0Maybe it all works now, but > that was the motivation for the change. The header and source I checked in to my branch date from my original work on FreeBSD for MIPS and I decided to use the existing spellings in those files rather than changing them to use the ones in the tree because using PG_ is fairly traditional and normal. I don't have an objection to PTE_ as such. JC is just trying to reduce diffs with my branch, but I don't care what the prefix on the name is as long as they're consistent and correct. I'm torn on the matter of cache attributes. I'd like for us to use consistent spellings for the cache coherency bits and to lump them all together in naming, which is why I like PG_C_UC and PG_C_CNC. The latter bit is defined in the various user's guides I've read as always meaning cacheable non-coherent. Is that same bit used on CPUs we care about to mean cacheable coherent? I don't really care, I suppose, as long as the bits are grouped (e.g. PG_C_*) and consistent between XKPHYS and PTE names. I'd prefer for us to not have cases where the same PTE with the same bits set are coherent on some CPUs and not coherent on others, but it sounds like that may be beyond our control. Thanks, Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinkTYuPjSNTTZxzU7iHWi4eXqQSyiUkNFRkP_FF>