From: Johannes Schauer <j.schauer@email.de>
To: Vagrant Cascadian <vagrant@freegeek.org>
Cc: Riku Voipio <riku.voipio@iki.fi>,
qemu-devel@nongnu.org, 632192@bugs.debian.org
Subject: Re: [Qemu-devel] Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
Date: Fri, 29 Jul 2011 17:21:59 +0200 [thread overview]
Message-ID: <20110729152159.GA9135@hoothoot> (raw)
In-Reply-To: <20110729125250.GJ27917@talon.fglan>
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
next prev parent reply other threads:[~2011-07-29 15:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-23 5:47 [Qemu-devel] [PATCH] add QEMU_LD_PREFIX environment variable josch
2011-07-23 5:47 ` josch
2011-07-28 8:41 ` Riku Voipio
2011-07-28 11:24 ` Johannes Schauer
2011-07-28 16:50 ` Geert Stappers
2011-07-28 17:28 ` Alexander Graf
2011-07-29 12:52 ` [Qemu-devel] Bug#632192: " Vagrant Cascadian
2011-07-29 15:21 ` Johannes Schauer [this message]
2011-07-30 13:58 ` Riku Voipio
2011-07-31 11:51 ` [Qemu-devel] [PATCH] introduce environment variables for all qemu-user options j.schauer
2011-07-31 12:12 ` Peter Maydell
2011-07-31 21:40 ` Johannes Schauer
2011-08-05 10:04 ` Peter Maydell
2011-08-06 6:54 ` Johannes Schauer
2011-08-20 17:29 ` Yann Dirson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110729152159.GA9135@hoothoot \
--to=j.schauer@email.de \
--cc=632192@bugs.debian.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
--cc=vagrant@freegeek.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).