Messages in this thread | | | From | Mike Frysinger <> | Date | Fri, 13 Aug 2010 17:59:41 -0400 | Subject | Re: [GIT PULL] core/hweight changes for v2.6.35 |
| |
On Fri, Aug 13, 2010 at 17:56, H. Peter Anvin wrote: > On 08/13/2010 02:42 PM, Mike Frysinger wrote: >> On Mon, May 17, 2010 at 17:21, Ingo Molnar wrote: >>> arch/alpha/include/asm/bitops.h | 18 +++++---- >>> arch/ia64/include/asm/bitops.h | 11 +++-- >>> arch/sparc/include/asm/bitops_64.h | 11 +++-- >>> arch/x86/include/asm/bitops.h | 4 +- >>> include/asm-generic/bitops/arch_hweight.h | 25 ++++++++++++ >>> include/asm-generic/bitops/const_hweight.h | 42 ++++++++++++++++++++ >>> include/asm-generic/bitops/hweight.h | 8 +--- >> >> did this miss Blackfin because the original patch was against the >> 2.6.34 tree ? just wondering why it now build fails ... >> >> doing a simple grep shows that the new "tile" arch may also be broken >> as it uses "hweight32" ... >> >> considering __sw_hweightX only exist when the generic hweight is in >> play, wouldnt it make sense to have >> include/asm-generic/bitops/arch_hweight.h not always define things ? >> then most arches can simply pull in >> include/asm-generic/bitops/hweight.h without having to worry about the >> random inner details of hweight cruft. >> > > __sw_hweightX can exist even when generic hweight isn't in use per se, > because the arch implementation can wrapper the software implementation. > This is the case on x86, for example -- most x86 CPUs don't have popcnt > yet, so on those the x86 implementation end up calling the > __sw_hweight*() implementations.
but those targets still define CONFIG_GENERIC_HWEIGHT right ? so at the least, we should be wrapping the prototypes in linux/bitops.h with that ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |