[PATCH] Suggested FreeBSD merge
Matthew Dillon
dillon at apollo.backplane.com
Sun Nov 14 12:48:27 PST 2004
I think we'll implement the kernel-supplied mapped library method to
deal with htonl and friends.
I've done some experimentation and it looks utterly trivial. This is
what we do:
* Create an ELF section containing an array of function pointers.
e.g. __section(".klib-dragonfly01") uint32_t (*htonl)(uint32_t hostlong);
(pointers within this section would be at fixed offsets so we might
either need some assembly to export the symbols or otherwise be very
careful about the order in which the support code declares the lib
functions).
* The program would supply default functions which the kernel would then
be able to override. The purpose of supplying a default function is
multi-fold:
- for backwards compatibility.
- so the program will still work even on kernels that do not support
the particular library version requested.
- so feature(s) (whole libraries or individual functions) can be
disabled on the kernel-side of things via sysctls.
* The kernel detects the ELF section when the program is exec'd and
automatically maps the kernel-optimized override/replacement functions
and then modifies the appropriate vectors in the ELF section.
(1) maps the kernel-supplied library into user memory or uses a
permanent kernel mapping that is user accessible.
(2) Adjusts the pointers in the ELF section as appropriate to point
to the kernel-supplied library.
We can use the same mechanism to implement our new system call layer.
The ELF section name would supply the version information to the kernel
so the kernel knows which vector set to use. This means:
* No more guessing about the sysvec, the kernel is told exactly which
sysvec the user program expects.
* Ability to implement compatibility functions or provide a mechanism
whereby the user program itself can execute a default function which
loads a compatibility library if the kernel cannot supply the requested
library / syscall set.
* Ability to abstract and optimize vectors for threaded vs non-threaded
programs.
* No more need to hack system call assembly for libc. libc is able to
take a hands-off approach and simply assume that the system call is
available and call it through the library vector.
* Ability to optimize system calls that can internally use a shared memory
interface. For example, time(), clock_gettime(), and so forth. e.g.
if the kernel decides that the TSC is useable it would supply a syscall
function that just uses the TSC instruction rather then entering into
the kernel.
And much, much more.
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
More information about the Submit
mailing list