Skip to contentSkip to conversation

avoid naming conflict around __ipipe_irq_handler

PATCH In review Jan Kiszka 2 participants 3 messages Dec 29, 2007 – Dec 30, 2007

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

PATCH 3/5 avoid naming conflict around __ipipe_irq_handler

There is already a definition of __ipipe_irq_handler. So, we either need to more the real ipipe_irq_handler_t into ipipe_base.h, or rename this local variant to __ipipe_irq_handler_t, or simple drop this refactoring. This patch starts with applying the latter - the easiest one :->

Jan

---
 include/asm-x86/ipipe_32.h |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)
include/asm-x86/ipipe_32.h +2 -5
Index: linux-2.6.24-rc6-xeno/include/asm-x86/ipipe_32.h
===================================================================
@@ -125,11 +125,8 @@ static inline unsigned long __ipipe_ffnz
 
 DECLARE_PER_CPU(struct pt_regs, __ipipe_tick_regs);
 
-typedef void (__ipipe_irq_handler)(unsigned irq,
-				   void *cookie);
-
 static inline void __ipipe_call_root_xirq_handler(unsigned irq,
-						  __ipipe_irq_handler *handler)
+						  void (*handler)(unsigned, void *))
 {
 	struct pt_regs *regs = &__raw_get_cpu_var(__ipipe_tick_regs);
 

@@ -161,7 +158,7 @@ void irq_enter(void);
 void irq_exit(void);
 
 static inline void __ipipe_call_root_virq_handler(unsigned irq,
-						  __ipipe_irq_handler *handler,
+						  void (*handler)(unsigned, void *),
 						  void *cookie)
 {
 	irq_enter();
#1 lore raw
Quoted 5 lines · Jan Kiszka

There is already a definition of __ipipe_irq_handler. So, we either need to more the real ipipe_irq_handler_t into ipipe_base.h, or rename this local variant to __ipipe_irq_handler_t, or simple drop this refactoring. This patch starts with applying the latter - the easiest one :->

There is no naming conflict, since they describe the same type with different even if close names on purpose. __ipipe_irq_handler is only a local short-hand to reduce visual pollution; as a matter of fact, the assembly code itself depends on the handler prototype, despite it cannot rely on any C-defined type, so the problem - if any - starts even before this local definition, and if you happen to change ipipe_irq_handler_t, then you could just not miss fixing __ipipe_irq_handler in the same move.

The only sane way to avoid defining this short-hand is indeed to move ipipe_irq_handler_t to linux/ipipe_base.h.

Signature · 1 line
Philippe.
author
#2 lore raw
Quoted 9 lines · Philippe Gerum
Quoted 5 lines · Jan Kiszka

There is already a definition of __ipipe_irq_handler. So, we either need to more the real ipipe_irq_handler_t into ipipe_base.h, or rename this local variant to __ipipe_irq_handler_t, or simple drop this refactoring. This patch starts with applying the latter - the easiest one :->

There is no naming conflict, since they describe the same type with different even if close names on purpose. __ipipe_irq_handler is only a

Sorry for remaining unclear: I was referring to the __ipipe_irq_handler helper macro from linux/ipipe.h. They may happen to live happily side by side, but it is far from being clean.

Quoted 9 lines

local short-hand to reduce visual pollution; as a matter of fact, the assembly code itself depends on the handler prototype, despite it cannot rely on any C-defined type, so the problem - if any - starts even before this local definition, and if you happen to change ipipe_irq_handler_t, then you could just not miss fixing __ipipe_irq_handler in the same move.

The only sane way to avoid defining this short-hand is indeed to move ipipe_irq_handler_t to linux/ipipe_base.h.

Jan