Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
On Fri, Jul 29, 2011 at 05:21:59PM +0200, Johannes Schauer wrote: 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 This is a legacy option that could be removed already. The -U LD_PRELOAD replaces this option. The only known user of this option (scratchbox) has migrated -U LD_PRELOAD years ago. -singlestep - QEMU_SINGLESTEP -strace - QEMU_STRACE also, there already is the QEMU_STRACE environment variable which could be incorporated into the solution? Else names look good to me. 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? getsubopt would mean that passing enviroment variable contents with commas wouldn't work. Perhaps that would still be an acceptable limitation. Riku -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
On Thu, Jul 28, 2011 at 11:41:09AM +0300, Riku Voipio wrote: On Sat, Jul 23, 2011 at 07:47:49AM +0200, josch wrote: This could be avoided by setting the proposed environment variable QEMU_LD_PREFIX to the just created debian rootfs. As mentioned earlier, the usage of the -L option is not possible in this scenario because qemu-user is only implicitly called by the binfmt mechanism. What worries me here is that we are beginning to add a enviroment variable for each and every command line option of qemu linux-user. I think it would be better to have a wrapper binary to be registered as the binfmt runner. 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... 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... live well, vagrant -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
On Sat, Jul 23, 2011 at 07:47:49AM +0200, josch wrote: This could be avoided by setting the proposed environment variable QEMU_LD_PREFIX to the just created debian rootfs. As mentioned earlier, the usage of the -L option is not possible in this scenario because qemu-user is only implicitly called by the binfmt mechanism. What worries me here is that we are beginning to add a enviroment variable for each and every command line option of qemu linux-user. I think it would be better to have a wrapper binary to be registered as the binfmt runner. 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. Riku -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
Hi, On Thu, Jul 28, 2011 at 11:41:09AM +0300, Riku Voipio wrote: On Sat, Jul 23, 2011 at 07:47:49AM +0200, josch wrote: This could be avoided by setting the proposed environment variable QEMU_LD_PREFIX to the just created debian rootfs. As mentioned earlier, the usage of the -L option is not possible in this scenario because qemu-user is only implicitly called by the binfmt mechanism. What worries me here is that we are beginning to add a enviroment variable for each and every command line option of qemu linux-user. Are there other environment variables? I didnt see any? (well besides QEMU_STRACE that is) I think it would be better to have a wrapper binary to be registered as the binfmt runner. If you need help with writing something - dont hesitate to ask for help. I'm very interested in having this functionality working because of the reasons I gave in my initial mail. [1] 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. What other options are there that would be interesting for binfmt? I was also sending this patch to qemu-devel list a month ago but got no reply. [2] As I said - if you would like a wrapper or a generic setup for mapping env variables to commandline parameters and dont have time to do it yourself, dont hesitate to delegate some work to me :) @Geert Stappers: you are patching bsd-user/main.c and darwin-user/main.c as well. I take it that you did test your changes on those platforms? does it work there as well? I have no clue of darwin but is it really useful there? cheers, josch [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632192#5 [2] http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00459.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
On Thu, Jul 28, 2011 at 01:24:47PM +0200, Johannes Schauer wrote:
@Geert Stappers:
you are patching bsd-user/main.c and darwin-user/main.c as well. I take
it that you did test your changes on those platforms? does it work there
as well? I have no clue of darwin but is it really useful there?
They only check I did,
was checking if BSD and Darwing have getenv(), they do.
I consider the
+/* read interp_prefix from environment variable */
+if (getenv(QEMU_LD_PREFIX) != NULL) {
+interp_prefix = getenv(QEMU_LD_PREFIX);
to Darwin and BSD as harmless. In fact only reason for those additional
lines were to bring attention to those operating systems.
With the idea^Whope of better acception from upstream.
Cheers
Geert Stappers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
