Although I remain skeptical that it is net benefit to have the
module loader in the kernel, I like the fact that your change is a net
deletion of 226 lines, which I think should be reason enough to apply
it if it has no disadvantages.
I was wondering if there is any other ultimate benefit to your
change. Is there something new that it would enable me to do,
something that I could do more easily, something that would run
faster, consume less memory, etc.? The only thing that comes to mind
is perhaps loading certain very well behaved self-contained user level
shared libraries, like perhaps some compression, encryption or
non-floating-point math functions.
Regarding the .init sections, I believe that there are
currently no modules with exception table entries pointing into .init.
So, if you adopt a policy that the .init section will be loaded
contiguously and not dropped if there is an exception table entry
pointing into .init, which currently happens ~0% of the time, you
allocate init and non-init sections the remaining ~100% of the time.
I believe this would allow for allocating smaller non-init sections
with kmalloc for better memory efficiency for small modules, which
will make it more practical have divide some modules into smaller
pieces that aren't always all needed together. I should also check
and see if kmalloc returns pointers in the 4MB kernel huge page on x86,
which would improve TLB usage.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"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.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:43 EST