Cleanup of module code

From: Keith Owens (kaos@ocs.com.au)
Date: Tue Mar 14 2000 - 20:22:49 EST


On Tue, 14 Mar 2000 09:38:27 -0800 (PST),
Linus Torvalds <torvalds@transmeta.com> wrote:
>What I'd really like to see:
> - get rid of __NO_VERSION__ entirely

Then every module object contains

const char __module_kernel_version[] __attribute__((section(".modinfo"))) =
"kernel_version=" UTS_RELEASE;

and the linker barfs on duplicate symbols. It needs a more intelligent
linker, make that symbol static or append a source specific string to
the symbol. The last two need changes to modutils. It would be more
reliable to make __module_kernel_version static, include it in all
components of a module load object and have insmod check that all the
individual components had the same module version.

> - get rid of the silly EXPORT_SYMTAB requirements entirely.

Agreed.

> - every single file should be able to do EXPORT(), and let's use
> something like "make checkconfig" to make sure that they are correctly
> marked in the makefiles as requireing the module treatment, instead of
> the current EXPORT_SYMTAB thing that causes errors if you want to make
> individual .s or .o files with "make drivers/xxxx/yyyy.s"

I would like to completely remove the distinction between builtin
objects and module objects. Compile everything as if it were a module
(-DMODULE). Constructs like __initfunc are compiled in all cases
instead of becoming a no-op in modules. If you install code as a
module then insmod would treat __initfunc etc. as normal text. If you
want an object built into the kernel then use a kernel specific
intelligent linker to take the desired objects and build a kernel from
them. Link order and preventing an object being loaded both in kernel
and as a module are obviously problems to be solved.

>The versioning flags could equally easily be handled by a very simple
>macro

The symbol versioning in current Makefiles is broken. The Makefile
logic for genksyms must be redone, along with some other Makefile
cleanups. Definitely a 2.5 project.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:29 EST