Re: loader/stage2 interaction

[John Reiser <jreiser BitWagon com>]

Chris Lumens wrote:

> - Part of the last one... we should copy the stage2 image out of its
>   initial location.  My reasoning for this is still that it makes
>   error handling easier when the repo has trouble.  This requires
>   making the repo editor more useful too.
> 
>   Problem:  This increases the memory requirements, which no one likes.

Small is good, but which specific memory requirements are we talking about?

If execution-time address space, then "ldd anaconda-runtime/loader/loader" shows
        linux-gate.so.1 =>  (0x00110000)
        libnewt.so.0.52 => /usr/lib/libnewt.so.0.52 (0x00c6c000)
        libslang.so.2 => /usr/lib/libslang.so.2 (0x00cbb000)
        libz.so.1 => /lib/libz.so.1 (0x00ca5000)
        libpopt.so.0 => /lib/libpopt.so.0 (0x00a83000)
        libdhcp-1.99.so.1 => /usr/lib/libdhcp-1.99.so.1 (0x00de3000)
        libnl.so.1 => /usr/lib/libnl.so.1 (0x0016d000)
        libdhcp4client-4.0.so.0 => /usr/lib/libdhcp4client-4.0.so.0 (0x001be000)
        libdhcp6client-1.0.so.2 => /usr/lib/libdhcp6client-1.0.so.2 (0x00db1000)
        libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x009c2000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x00c87000)
        libsepol.so.1 => /lib/libsepol.so.1 (0x00986000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00a4b000)
        libm.so.6 => /lib/libm.so.6 (0x00c3a000)
        libc.so.6 => /lib/libc.so.6 (0x00acf000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c65000)
        /lib/ld-linux.so.2 (0x00aaf000)
which suggests that several of those libraries might be used with
explicit dlopen()/dlclose() for various phases.  There is also a style
which uses a chain of execve() to handle various phases,
or even "code overlays" where the .text begins with a new main() from
a new file, but the .data+.bss+.stack remains the same.
If swap space is available, then a series of processes connected via
pipes can reduce the minimum RAM required.

If media storage space, then anaconda-runtime/loader/loader
does not use compression of the executable itself.  "upx --lzma"
reduces it from 237904 -> 84556 bytes, which is a ratio of 0.36.

Is stage2.img accessed dynamically as a compressed filesystem
that is not memory resident?  Is all of it uncompressed at once
before initial access?

--