[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200609272336.25007.arnd@arndb.de>
Date: Wed, 27 Sep 2006 23:36:24 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Robin Getz <rgetz@...ckfin.uclinux.org>
Cc: luke Yang <luke.adi@...il.com>, Andrew Morton <akpm@...l.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18
Am Wednesday 27 September 2006 23:22 schrieb Robin Getz:
> Systems that use static inline:
> ./asm-m32r/system.h:static inline void local_irq_enable(void)
> ./asm-sh64/system.h:static __inline__ void local_irq_enable(void)
> ./asm-sh/system.h:static __inline__ void local_irq_enable(void)
> ./asm-xtensa/system.h:static inline void local_irq_enable(void)
>
> With the "optimizations" that gcc4 is making with inline being only a
> "suggestion", I think I would prefer to stick with the macro, unless there
> is violent opposition.
Note that the architectures that do the macro are the ones that
were there first, while the four above are relatively new. They may
well have gotten the same comment ;-)
For a single statement, it doesn't really matter much
whether you're using a macro or an inline function, but the longer
the macro gets, the more reason there is to change it.
In particular, new gcc versions actually do a pretty good job
at deciding when to use an out-of-line function and it may make
your code better if you let it.
> As Mike pointed out - we are sheep - we just do what the majority (18/22)
> of other people do.
Not a bad strategy in general. An even better strategy is to do
what the better architecture implementations in linux do and
to apply common sense. "better" of course is rather subjective,
but I typically recommend looking at arch/parisc as a good example.
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists