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

From: Philippe Gerum
Date: Tue Jun 21 2005 - 04:11:55 EST

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:

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:

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

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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at