Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > +struct __cond_call_struct {
Calling structs *_struct is severly deprecated and will cause some people to make fun of your code. > + const char *name; > + void *enable; > + int flags; > +} __attribute__((packed)); The packed doesn't seem to be needed. There will be padding at the end anyways because the next one needs to be aligned. > + > + > +/* Cond call flags : selects the mechanism used to enable the conditional > calls > + * and prescribe what can be executed within their function. This is > primarily > + * used at reentrancy-unfriendly sites. */ > +#define CF_OPTIMIZED (1 << 0) /* Use optimized cond_call */ > +#define CF_LOCKDEP (1 << 1) /* Can call lockdep */ > +#define CF_PRINTK (1 << 2) /* Probe can call vprintk */ > +#define CF_STATIC_ENABLE (1 << 3) /* Enable cond_call statically */ Why is that all needed? Condcall shouldn't really need to know anything about all this. They're just a fancy conditional anyways -- and you don't tell if() that it may need to printk. Please consider eliminating. > +#define _CF_NR 4 > + > +#ifdef CONFIG_COND_CALL > + > +/* Generic cond_call flavor always available. > + * Note : the empty asm volatile with read constraint is used here instead > of a > + * "used" attribute to fix a gcc 4.1.x bug. */ What gcc 4.1 bug? > +#define cond_call_generic(flags, name, func) \ > + ({ \ > + static const char __cstrtab_name_##name[] \ > + __attribute__((section("__cond_call_strings"))) = #name; \ > + static char __cond_call_enable_##name = \ > + (flags) & CF_STATIC_ENABLE; \ > + static const struct __cond_call_struct __cond_call_##name \ > + __attribute__((section("__cond_call"))) = \ > + { __cstrtab_name_##name, \ > + &__cond_call_enable_##name, \ > + (flags) & ~CF_OPTIMIZED } ; \ > + asm volatile ( "" : : "i" (&__cond_call_##name)); \ > + (unlikely(__cond_call_enable_##name)) ? \ > + (func) : \ > + (__typeof__(func))0; \ > + }) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/