That is the current design of the kernel. There are 39 C files
in the 2.1.103 kernel that contain "#ifdef CONFIG_foo_MODULE". Changing
any of the corresponding build options will build an incompatible
kernel. It is currently more accurate to say that when you select
modules with "make config", you are determining what modules the kernel
will be compatible with.
If you want new semantics that say that any module can be
loaded into any configuration of the kernel of the same version number
(except if the module is compiled in), you would have to change a lot
more than the math emulation, and that also means adding unnecessary
infrastructure to kernels that are configured with most items completely
deactivated. For example, it means that a kernel for an X-terminal would
still have to have the infrastructure for the Multiple Disk subsystem
(which is not a module but has subsidiary components that can be modules).
I could go on and on with sillier examples.
Here are some comments on the specifics of the modularized
math emulation patch:
[...]
>> Speed tends to be a particularly important metric for math [...]
>Looking at your patch, it makes these tests for things like
>math-not-present traps and ptrace interactions with fpu. I don't
>think these are important to anyone's benchmark, are they?
The code that you're referring was there already for the compiled in
math emulation. It's not something I added.
>I'm advocating taking the CONFIG_MATH_EMU_MODULE stuff out and having
>these tests all the time. That will not hurt performance at all,
>ever, for the emulation case.
It adds an extra procedure call to every math operation. In the
modularized case, every math operation calls the math_emulate
function in arch/i386/kernel/traps.c, which then calls math_emulate_local,
in arch/i386/math-emu/fpu_entry.c. In the non-modularized case,
math_emulate_local (which is named math_emulate) is called in this
case. I have an optimization in mind to fix this, but it involves
changing the assembly language call of math_emulate in
arch/i386/kernel/entry.S, so I need to figure out what registers
are available to use, and so on. If and when I am able to implement
this optimization (or somebody else does), then the relative savings
for the "compiled in" case will be smaller, which then would make
your suggestion less costly. I'll at least reconsider your
suggestion at that time if I'm not persuaded before then.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu