Hi, On 02/03/16 03:00, Will Deacon wrote: > On Wed, Feb 24, 2016 at 03:33:08PM +0000, Andre Przywara wrote: >> The pre_init stub consists of two syscalls mouting the host's FS >> via 9pfs and then calling the actual init binary, which can now >> use normal dynamic linking. >> Based on the x86 code provide an ARM and ARM64 implementation of >> that. Beside removing the need for static linkage it reduces the >> size of the kvmtool binary by quite a lot (numbers for aarch64): >> >> -rwxr-xr-x 1 root root 9952 Nov 16 14:37 guest/init >> -rwxr-xr-x 1 root root 512 Nov 16 14:37 guest/pre_init >> -rwxr-xr-x 2 root root 1284704 Nov 16 14:37 lkvm >> vs. the old version: >> -rwxr-xr-x 1 root root 776024 Nov 16 14:38 guest/init >> -rwxr-xr-x 2 root root 2050112 Nov 16 14:38 lkvm >> >> Tested on Midway and Juno. > > Hmm, I'm not super keen on switching behaviour like this on arm, where > it's not uncommon to build a static lkvm and transfer it to a remote > target and expect init to work. So are you concerned about a fully static root file system on the host, which does not provide libc.so and/or ld-linux.so at all? Is that really a use case? I had the impression that people use a statically linked kvmtool to avoid dependencies like to libfdt.so. In this case I am wondering if we should provide some switch to build a static lkvm with a static init if people are concerned, or we should ship a guest/init binary statically linked against musl libc, for instance: this is only 29K compared to the above multi-100 KB gcc version. Or is there some trick to build small static binaries linked against glibc? Actually by just looking at init.c: Should we code the whole of it in assembly? Apart from printf it only consists of syscalls. > Perhaps we could only do this when building a dynamic executable? This is of course an option as well. Cheers, Andre -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
