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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/