> Date: Sun, 26 Dec 2010 20:26:03 -0800 > From: Philip Guenther <[email protected]> > > On Sat, Dec 25, 2010 at 11:35 AM, Ted Unangst <[email protected]> wrote: > > On Sat, Dec 25, 2010 at 2:12 PM, Philip Guenther <[email protected]> > wrote: > >> Fix the naming of the atomic macros on amd64: right now, the > >> x86_atomic_*_l() macros actually operate on unsigned 32bit integers > >> instead of longs, so: > >> 1) change the callers to use the _u32 versions > >> 2) update the _ul definitions to bew the 64bit versions > >> 3) remove the _l macros > >> > >> Open question: perhaps the _ul macros should be removed too (they're > >> unused after this diff) and future code should just explicitly use the > >> _u32 or _u64 macros? > > > > This looks good, but I think we should delete the ul macro too. There > > should be very few "long" types running around in the kernel.
Actually we have quite a bit of "long" usage in the kernel; addresses, sizes, etc. etc. Basically everything that needs to be 32 bits on a 32-bit system and 64 bits on a 64-bit system is defined as a typedef of "long". What are these x86_atomic_*() macros used for? Well, we inherited them from NetBSD, and there they are used to make sharing code between i386 and amd64 easier. Now in OpenBSD we don't really share code like that, but I still think it should still be our goal to reduce the diffs between our i386 and amd64 codebase as much as possible. That means "variable" "long" variants of the atomic functions are probably needed in addition to the "fixed" 32-bit and 64-bit ones. Ultimately we should probably define a constent MI set of atomic interfaces. But until then I think it makes sense to keep the _l and _ul variants around. > That's simple enough, it just means deleting three '+' lines from the > atomic.h part of the diff, deleting the _l and _ul macros and leaving > just the x86_atomic_testset_i() macro (which is only used in lock.h). > I'm fine with that. > > oks? So I think Philip's origional diff should go in. The x86_multicast_ipi() removal should probably be a seperate commit though.
