On Fri, Jan 25, 2013 at 12:06 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Paul Turner <p...@google.com> wrote: > >> On Thu, Jan 24, 2013 at 11:19 PM, Ingo Molnar <mi...@kernel.org> wrote: >> > >> > * Fabio Estevam <feste...@gmail.com> wrote: >> > >> >> On Thu, Jan 24, 2013 at 12:19 PM, Ingo Molnar <mi...@kernel.org> wrote: >> >> >> >> > I suppose - is this patch warning-free both on 64-bit and 32-bit >> >> > systems? >> >> >> >> Yes, just confirmed that this patch is warning-free on both 64-bit and >> >> 32-bit machines. >> > >> > Apparently it's not all good, see the warning attached below. >> >> Yeah this patch is broken; this is not properly fixable as is without >> #ifdefs (or fixing the insanity that is atomic64_read). >> >> Specifically: >> >> On some architectures (e.g. x86_64) atomic64_read is typed long >> On some others (e.g. x86-32) it's typed long long >> On yet others (e.g. arm) it's typed u64 > > Hm, cannot we type atomic64_read() to u64 on x86-64 as well, and > fix other architectures? How widespread is this problem, have > you checked that perhaps?
I have not looked at how much fall-out this would cause. Ideally someone with a cross-compiing tool-chain or from the specific arches could take ownership of cleaning up their atomic64 implementations to avoid introducing more build pain. Theoretically, given the list above x86-64 is actually the outlier in assuming that it's just a long type; perhaps we can gain sufficient mileage by changing only the x86-64 implementation; which is much easier for us to validate :-). > > I'm all for clean, consistent types instead of #ifdef or > temporary variable uglies. Yes I agree this would be the best solution. > > Thanks, > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
