x86/atomic changes for v2.6.35
in [Kernel]
|
From: Geert Uytterhoeven on 19 May 2010 07:50 On Tue, May 18, 2010 at 00:45, Ingo Molnar <mingo(a)elte.hu> wrote: > Please pull the latest x86-atomic-for-linus git tree from: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-atomic-for-linus > > > out-of-topic modifications in x86-atomic-for-linus: > --------------------------------------------------- > lib/Makefile # 86a8938: lib: Add self-test for atomic64_t > lib/atomic64.c # 9757789: lib: Fix atomic64_add_unless retu > lib/atomic64_test.c # a5c9161: x86, atomic64: In selftest, disti > # 25a304f: lib: Fix atomic64_inc_not_zero te > # 9efbcd5: lib: Fix atomic64_add_unless test > # d7f6de1: x86: Implement atomic[64]_dec_if_ > # 8f4f202: lib: Only test atomic64_dec_if_po > # 86a8938: lib: Add self-test for atomic64_t Is having atomic64_t mandatory now? According to the allmodconfig build logs (http://kisskb.ellerman.id.au/kisskb/matrix/), several architectures (at least m68k and mips) don't have it. Furthermore, the test fails to compile on a few architectures that do have it (parisc, s390, sh, ...). <boilerplate> It's a pity this wasn't raised/resolved between its detection in linux-next and before it entered mainline... </boilerplate> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 19 May 2010 10:30 On 05/19/2010 04:46 AM, Geert Uytterhoeven wrote: > On Tue, May 18, 2010 at 00:45, Ingo Molnar <mingo(a)elte.hu> wrote: >> Please pull the latest x86-atomic-for-linus git tree from: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-atomic-for-linus >> >> >> out-of-topic modifications in x86-atomic-for-linus: >> --------------------------------------------------- >> lib/Makefile # 86a8938: lib: Add self-test for atomic64_t >> lib/atomic64.c # 9757789: lib: Fix atomic64_add_unless retu >> lib/atomic64_test.c # a5c9161: x86, atomic64: In selftest, disti >> # 25a304f: lib: Fix atomic64_inc_not_zero te >> # 9efbcd5: lib: Fix atomic64_add_unless test >> # d7f6de1: x86: Implement atomic[64]_dec_if_ >> # 8f4f202: lib: Only test atomic64_dec_if_po >> # 86a8938: lib: Add self-test for atomic64_t > > Is having atomic64_t mandatory now? > > According to the allmodconfig build logs > (http://kisskb.ellerman.id.au/kisskb/matrix/), > several architectures (at least m68k and mips) don't have it. > Furthermore, the test fails to compile on a few architectures that do have it > (parisc, s390, sh, ...). > > <boilerplate> > It's a pity this wasn't raised/resolved between its detection in linux-next and > before it entered mainline... > </boilerplate> > Is having atomic64_t mandatory? Not yet, I don't think, but it probably will be soon -- which is why there is a generic implementation available. All those architectures just need to select CONFIG_GENERIC_ATOMIC64 and voilà, problem solved. As far as your boilerplate is concerned, I think Linus made it clear at the Kernel Summit that is it not the obligation of x86/ARM/PowerPC to slow down to not break the smaller architectures; it's the responsibility of those architecture maintainers to keep up. Sorry. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Rothwell on 19 May 2010 10:40 Hi, On Wed, 19 May 2010 07:24:00 -0700 "H. Peter Anvin" <hpa(a)zytor.com> wrote: > > On 05/19/2010 04:46 AM, Geert Uytterhoeven wrote: > > <boilerplate> > > It's a pity this wasn't raised/resolved between its detection in linux-next and > > before it entered mainline... > > </boilerplate> > > As far as your boilerplate is concerned, I think Linus made it clear at > the Kernel Summit that is it not the obligation of x86/ARM/PowerPC to > slow down to not break the smaller architectures; it's the > responsibility of those architecture maintainers to keep up. Sorry. I don't think this reply has anything to do with the sentiments expressed by Geert above. My interpretation of his comments is just that it is a pity noone noticed the problem while it was only in linux-next and reported it widely (like on linux-arch) so something could have been done before it all Linus' tree. There was no suggestion of slowing the pace of development. -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au http://www.canb.auug.org.au/~sfr/
From: H. Peter Anvin on 19 May 2010 11:10 On 05/19/2010 07:36 AM, Stephen Rothwell wrote: > Hi, > > On Wed, 19 May 2010 07:24:00 -0700 "H. Peter Anvin" <hpa(a)zytor.com> wrote: >> >> On 05/19/2010 04:46 AM, Geert Uytterhoeven wrote: >>> <boilerplate> >>> It's a pity this wasn't raised/resolved between its detection in linux-next and >>> before it entered mainline... >>> </boilerplate> >> >> As far as your boilerplate is concerned, I think Linus made it clear at >> the Kernel Summit that is it not the obligation of x86/ARM/PowerPC to >> slow down to not break the smaller architectures; it's the >> responsibility of those architecture maintainers to keep up. Sorry. > > I don't think this reply has anything to do with the sentiments expr > by Geert above. My interpretation of his comments is just that it is a > pity noone noticed the problem while it was only in linux-next and > reported it widely (like on linux-arch) so something could have been done > before it all Linus' tree. There was no suggestion of slowing the pace > of development. It was discussed on linux-kernel -- note that there is no breakage for smaller architectures unless you enable the test directly or via randconfig. The other part is that generic atomic64_t has been available since middle of 2009, and was *also* discussed extensively on linux-kernel -- in fact, several of the smaller architectures added support at that time. That the breakage occurred because of an inconsequential test rather than real code is thus really nothing but fortunate. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Rothwell on 19 May 2010 11:30
On Wed, 19 May 2010 08:01:35 -0700 "H. Peter Anvin" <hpa(a)zytor.com> wrote: > > It was discussed on linux-kernel -- note that there is no breakage for > smaller architectures unless you enable the test directly or via randconfig. or allmodconfig or allyesconfig. > The other part is that generic atomic64_t has been available since > middle of 2009, and was *also* discussed extensively on linux-kernel -- > in fact, several of the smaller architectures added support at that > time. That the breakage occurred because of an inconsequential test > rather than real code is thus really nothing but fortunate. I don't disagree with any of that (except that an m68k allmodconfig build may well build fine without the test being built so maybe building the test needs a dependency). My point was that I keep hearing the "Linus said it is OK to break the other architectures" argument brought up where it really is not even relevant to the conversation. If anything, I guess Geert was taking a little dig at me because his problem should have been noticed among my build results. Unfortunately even I don't check all the build results all the time (I guess I hope that maintainers may have time to check them out once in a while). -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au http://www.canb.auug.org.au/~sfr/ |