Rather than having the kernel provide a special page which it fills
with code (which in turn means more kernel bloat, as multiple
implementations will need to be kept in an __init section), why not
allow mmap(2) mappings to be inherited across execve(2)?
Add a new MAP_INHERIT flag to specify which mappings are to be
retained, and a new syscall to get the list of inherited mappings?
Then the init process could check the machine architecture and map in:
- architecture-specific shared object
- libc and other shared objects which are "always" loaded
the magic for this could be hidden inside libc or ld.so, so the
init(8) code doesn't have to be modified (thus it will work with any
implementation of init(8)).
The same (clean, IMHO) mechanism could be used so that Linus has his
architecture-specific "magic page(s)", and Ulrich can reduce startup
latency (because some symbol resolving is already done and because
each process doesn't have to call mmap(2) as much, which saves
building page tables). All with a minimum of kernel code.
If preloading is done, then you would fall back to the old scheme. I
don't think it's necessary to optimise this case. Preloading is a
temporary measure.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/