Re: linux-kernel-digest V1 #146

Jacques Gelinas (jack@solucorp.qc.ca)
Mon, 7 Aug 95 13:08:35 EDT


> > Note that the kernel export functions aren't mean to to be a library.
> > If a user program needs the functionality of "strnlen()", it shouldn't
> > try to get it from the kernel. Similarly, if a kernel module needs
> > strnlen(), it should link it in itself, not try to get it from the
> > kernel.

> True. But on the other hand, is there any reason there shouldn't be a
> kernel-space shared library containing these common functions? If we
> link them all statically into modules, the modules will get big and
> fat.

> It would definitely be tricky, but it might be worth it.

Not tricky at all. It is already available :-)

When you load a module, all its public symbol are made available to
other module. This is the way module stack do work. Umsdos work
on top of the msdos module. ppp on top of shlc module and so on.

And the good news is that if you are using the depmod and modprobe utilities
(part of the modules-1.2.8.tar.gz package along with insmod) the stacking
is handled transparently. It is not more complicate to use.

One thing that Bjorn (maintainer of the modules package)
had done, but did not fully release, was the ability
for a module to export a specific list of symbol in the same way
the kernel publish a limit set (kernel/ksyms.c).

There is a problem with a "general" purpose module-library. Unlike the
user space libc.so, it is not pageable. All of it will occupy real memory.
So if we assemble a module made of generic functions that might be useful
to other module, we will end with a large module potentially fairly unused.

One thing that would be a neat idea though is a
"kernel module support library" containing some interesting functions
for module. This library could be compiled to a libkernel.a library. It would
be useful to avoid replication of code between different modules (and
avoid replication of bugs!).

Sure enough each module which use strnlen function would have a copy
of it. After some time we could do some analysis and find out
which functions are really popular in different modules and create
a "common" module containing those. Just by removing those functions
from libkernel.a, linking them as a module and relinking all the module
would enable this common module.

What about a new directory in the kernel hierachy "libmodule" ?

--------------------------------------------------------
Jacques Gelinas (jacques@solucorp.qc.ca)
Ever think of installing unix without partitionning ?
Use UMSDOS, and enjoy LINUX!