On Wed, Sep 13, 2000 at 12:26:39AM +0100, Russell King wrote:
> If its 15K, and you're compiling raid as modules, why can't this code
> also be compiled as a module in the architecture tree? Last time I
> looked, modprobe handled dependencies between modules.
With the code as-is, you'd have half the module would be under
arch/foo/lib/ and the other half in drivers/block/xor.c. I can't
think of a non-fragile way to create a composite module from objects
in two different directories.
This implies that we either need to give up on sharing the code
in xor.c (bad) or use multiple modules (ok). Now, modprobe cannot,
to my knowledge, handle circular dependancies, and even if it could
relying on such would be bad design. So we need to have some straight
line ordering from raid5.o -> xor.o -> xor_alpha.o
or raid5.o -> xor_alpha.o -> xor.o.
By itself, this isn't too bad. One solution is to have xor.o depend
on a definition for `xor_active_template' which it gets from xor_alpha.o,
which contains the set of routines to use. The only questionable part
is that constructor for xor_alpha.o needs to call back into xor.o to
figure out which routine is fastest.
But what to do about ports that don't define custom xor routines?
The obvious place to put this sort of thing is in lib/, but we've
never built modules out of there before. And even if we did, we'd
have to prevent them from being built on systems that do define
their own xor routines, since the module dependancy scheme requires
that only one module satisfy the request for xor_active_template.
Further, i386 defines custom xor routines that can only be used on
late model hardware; if you're running on a 486, you fall back to
the generic routines. So we can't really leave the generic bits
out, but have to figure out how to get them built differently on
different architectures (without and without defining xor_active_template).
So the only way I can think to get things built without massive code
replication is to #include xor.c code into arch/foo/lib/xor_foo.c.
Any arch that does not implement custom xor routines will have to have
an entry in its arch/foo/lib/Makefile to build a module from source
living in lib/. I'm not fond of this notion.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:19 EST