On 1 May 2013 22:43, Al Viro <v...@zeniv.linux.org.uk> wrote: > On Wed, May 01, 2013 at 10:04:17PM +0100, James Hogan wrote: >> Al's commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate >> cond_syscall and SYSCALL_ALIAS declarations") broke the build on >> blackfin and metag due to the following code: >> >> #ifndef SYMBOL_NAME >> #ifdef CONFIG_SYMBOL_PREFIX >> #define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x >> #else >> #define SYMBOL_NAME(x) x >> #endif >> #endif >> #define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x)) >> >> __stringify literally stringifies CONFIG_SYMBOL_PREFIX ##x, so you get >> lines like this in kernel/sys_ni.s: >> >> .weak CONFIG_SYMBOL_PREFIXsys_quotactl >> .set CONFIG_SYMBOL_PREFIXsys_quotactl,CONFIG_SYMBOL_PREFIXsys_ni_syscall >> >> The patches in Rusty's modules-next tree such as "CONFIG_SYMBOL_PREFIX: >> cleanup." clean up the whole mess around symbol prefixes, so this patch >> just attempts to fix the build in the mean time. The intermediate >> definition of SYMBOL_NAME above isn't used and is incorrect when >> CONFIG_SYMBOL_PREFIX is defined as CONFIG_SYMBOL_PREFIX is a quoted >> string literal, so define __SYMBOL_NAME directly depending on >> CONFIG_SYMBOL_PREFIX. > > Oh, hell... Guys, my deep apologies - what happened is that this thing > has been caught in -next, rebase done here (on top of Rusty's commit) > and *not* pushed to linux-next. Unfortunately, folks had been too polite > and didn't keep kicking me - mistake, since the whole thing got forgotten ;-/ > Sigh...
No worries. Unfortunately after the tip of linux-next started working again with Rusty's commit it sort of fell off my radar. Cheers James -- 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/