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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
