Re: [PATCH 1/2] I-pipe: Core implementation

[Philippe Gerum <rpm@xenomai.org>]

Karim Yaghmour wrote:
> Philippe Gerum wrote:
> 
>>There's a fourth one (ipipe/x86.c) added by the arch-dependent patch, 
>>but yes, I agree that this could sound rather overkill to have this 
>>support in its own dir, especially a top-level one. The files under 
>>ipipe/ can be built as a loadable module, hence the current layout.
>>Would you see this belonging to, e.g., the driver tree instead?
> 
> 
> How about this instead:
> 
> Arch-indepedent parts:
> ----------------------
> include/linux/ipipe.h
> 
> kernel/ipipe/Kconfig      (formerly ipipe/Kconfig)
> kernel/ipipe/Makefile     (formerly ipipe/Makefile)
> kernel/ipipe/core.c       (formerly kernel/ipipe.c)
> kernel/ipipe/generic.c    (formerly ipipe/generi.c)
> 
> Arch-dependent parts:
> ---------------------
> include/asm-i386/ipipe.h
> 
> arch/i386/kernel/ipipe-core.c  (formerly arch/i386/kernel/ipipe.c)
> arch/i386/kernel/ipipe-root.c  (formerly ipipe/x86.c)
> 
> Seems to me that the above makes more sense. Albeit you would have
> parts of the module in kernel/ipipe/* and the rest in
> arch/*/kernel/ipipe*.

I'm pondering now if having the i-pipe buildable as a module is still 
relevant, like it was during the early Adeos times. This was mainly used 
to reduce the compile-debug-reboot cycle, so that we could just unload 
the module for testing some non-critical Adeos features which were not 
related to the interrupt pipeline. This becomes clearly irrelevant in 
the i-pipe case (any bug in the i-pipe would very likely make the box go 
south anyway).
Additionally, dealing with a dynamically loadable i-pipe adds a small 
but permanent overhead for testing if the pipeline is enabled during 
internal operations.

Any objection to make the pipeline a static-only feature?

-- 

Philippe.