Messages in this thread | | | From | Miguel Ojeda <> | Date | Mon, 3 Sep 2018 12:40:38 +0200 | Subject | Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax |
| |
Hi Geert,
On Mon, Sep 3, 2018 at 8:42 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Miguel, > > On Sat, Sep 1, 2018 at 12:41 AM Miguel Ojeda > <miguel.ojeda.sandonis@gmail.com> wrote: >> On Sat, Sep 1, 2018 at 12:10 AM, Miguel Ojeda >> <miguel.ojeda.sandonis@gmail.com> wrote: >> > arch/parisc/boot/compressed/misc.c:#define malloc malloc_gzip >> > include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL) >> > lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL) >> > include/linux/compiler_types.h:#define noinline_for_stack noinline >> > include/linux/raid/pq.h:#define noinline __attribute__((noinline)) >> > tools/include/linux/compiler.h:#define noinline >> > arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1); >> >> A better list, searching for all attributes used anywhere in the kernel: >> >> git grep -E '^\s*#define\s+(address_space|alias|aligned|always_inline|assume_aligned|bitwise|bnd_legacy|cold|common|const|constructor|context|deprecated|designated_init|destructor|error|externally_visible|flatten|force|format|format|gnu_inline|hot|hotpatch|indirect_branch|latent_entropy|long_call|malloc|may_alias|mode|model|naked|nocast|noclone|noderef|noinline|no_instrument_function|nonnull|no_randomize_layout|noreturn|no_sanitize_address|optimize|packed|pure|randomize_layout|regparm|require_context|safe|section|syscall_linkage|target|tls_model|unused|used|user|vector_size|visibility|warning|warn_unused_result|weak)(\(|\s|$)' >> >> arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1); >> /* Silence gcc. */ >> arch/parisc/boot/compressed/misc.c:#define malloc malloc_gzip >> arch/powerpc/xmon/ansidecl.h:#define const >> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:#define error(fmt, >> args...) bioslog(ERROR, fmt, ##args) >> include/linux/compiler_attributes.h:#define noinline >> __attribute__((noinline)) >> include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL) >> include/linux/raid/pq.h:#define noinline __attribute__((noinline)) >> lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL) >> tools/include/linux/compiler-gcc.h:#define noinline >> __attribute__((noinline)) >> tools/include/linux/compiler.h:#define noinline >> tools/testing/selftests/futex/include/logging.h:#define error(message, >> err, args...) \ >> >> None of these should make a problem. And it would may avoid people >> using such common-name-macros in the future ;-) > > That's very fragile. > Who knows all (current and future) attribute names by heart, and that defining > them could have such side effects?
Please see the email I sent after that one -- I clarified that this was more about the current state and that in v3 it will be changed, if only to avoid surprises in the future for ourselves. I agree with you and, as Rasmus pointed out, we will use the macros anyway.
> > At least "alias", "force", "format", "mode", "model", "optimize", "target" are > names I wouldn't hesitate to use as a macro name in a driver...
A macro with a lowercase, short & common name is not the best idea in my opinion; if only because of clarity for future readers. Unless it really improved the code readability for some reason in a particular case, I would avoid it. But to each his own! :-)
Thanks for reviewing!
Cheers, Miguel
| |