> Items For Discussion
>
> #1 - shared kinit
>
> "kinit" is _the_ early userspace binary -- but not necessarily the only
> one. Peter Anvin and Russell King have several binaries in the klibc
> tarball, gzip, ash, and several smaller utilities. Peter also put work
> into making klibc a shared object -- that doesn't need an shlib loader.
> It's pretty nifty how he does it, IMO: klibc.so becomes an ELF
> interpreter for any klibc-linked binaries. klibc-linked binaries are,
> to the ELF system, static binaries, but they wind up sharing klibc.so
> anyway due to this trick.
>
> Anyway, there is a certain elegance in adding coding to kinit instead of
> an explosion of binaries and shell scripts. The other side of that coin
> is that with elegance you sacrifice some ease of making changes. I am
> 60% certain we want a shared klibc and multiple binaries, but am willing
> to be convinced in either direction. If you think about it, there _are_
> several benefits to leaving kinit as the lone binary in the stock kernel
> early userspace build, so the decision is not as cut-n-dry as it may
> immediately seem.
One idea I experimented some time ago with (and can revive after
some sleep) is, rather than interpreting cpio in the kernel, objcopy
a binary into a init and copy that into pagecache in a ramfs/libfs
file system. The population was all initfunctions, trying to make
it disappear at runtime. /dev/initrd was left for userspace to
expand the rest of the loaders. With libfs, the write code reinstated
so standard directories, device nodes, console and initrd nodes
can be created and opened in userspace, further shrinking the static
linked-in code.
This argues that this initial code is unshared and uncompressed
(or rather, compressed like the rest of the kernel); for shared we
would have to copy a couple of pieces this way. It traded off a
table of offset,length,mode,name with cpio headers and parsing.
I had this running on 2.4.19-pre10 (around the time of the kernel
summit, just before the fixed directory link counts went in) with
busybox. (I seperated the 2.4 compat vs 2.5 stuff at that time).
Comments?
milton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:24 EST