kernel DSO

[Alan Modra <amodra at bigpond dot net dot au>]

I'd like to extend the kernel DSO support a little.

Currently, people use the kernel DSO to provide alternate entry to
syscalls, or for functions to replace syscalls such as gettimeofday, and
to provide signal handler return trampolines with associated dwarf2
.eh_frame info.  The "syscall replacement" model has naturally led to
an implementation where access to the kernel DSO functions is via glibc.

On powerpc*-linux, we'd like to do more than just replace syscalls.  We
would like the kernel to provide versions of memcpy, locking primitives,
cache invalidation functions etc., all optimized for the particular CPU
detected by the kernel.  Ideally, user apps, shared libs and glibc
itself should be able to use these functions directly, without bouncing
through some sort of glibc stub in addition to the normal plt call
stubs.  To do this, we intend to make the kernel DSO export ELF symbol
tables, dynamic section and so forth just like a normal DSO.  We'd need
to arrange that the kernel DSO be treated just like any other ELF shared
lib with regards to symbol resolution, and have ld.so search the kernel
DSO before libc.  Or possibly some other scheme that has the same
effect.

So, my question is:  Does this idea have some fundamental flaw that
makes it unacceptable?  The benefits should be clear:  A faster call
path, and no jumps to magic addresses since the kernel DSO exports
a proper symbol table.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre