On Fri, Jul 29, 2011 at 05:52:50AM -0700, Vagrant Cascadian wrote: > setting up a wrapper makes trivial cross-architecture chroots harder > as you'll have to copy two binaries into the chroot, and i'm not sure > if it would work at all, as the wrapper will need to somehow emulate > it's own interpreter...
Agreed - this makes a wrapper not an option. I didnt think of that. > > Alternatively we should have a generic setup for mapping enviroment > > variables to command line options. Now we get special per-option > > code every time someone needs to setup a command line option from > > binfmt. > > this would seem a bit better alternative to me... So if we agree on using environment variables to pass options to qemu-user we next need to agree on how to name the options. The following commandline arguments exist (in order as they are checked in linux-user/main.c) and I shortly described and proposed a name for the environment variable in the same line. -d (activate log) - QEMU_LOG -D (logfile) - QEMU_LOGFILE -E (set target env variabe) - QEMU_SET_ENV -U (unset target env variabe) - QEMU_UNSET_ENV -0 (set target argv[0]) - QEMU_ARGV0 -s (stack size) - QEMU_STACK_SIZE -L (elf interpreter prefix) - QEMU_LD_PREFIX -p (page size) - QEMU_PAGESIZE -g (listen for gdb on port) - QEMU_GDB -r (uname) - QEMU_UNAME -cpu (cpu model) - QEMU_CPU -B (guest base) - QEMU_GUEST_BASE -R (reserved virtual address) - QEMU_RESERVED_VA -drop-ld-preload - QEMU_DROP_LD_PRELOAD -singlestep - QEMU_SINGLESTEP -strace - QEMU_STRACE also, there already is the QEMU_STRACE environment variable which could be incorporated into the solution? the -E and -U options can be specified several times so the environment variables should be able to receive a list - maybe in the getsubopt(3) style? So what do you think? cheers, josch
