qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Riku Voipio <riku.voipio@iki.fi>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: [Qemu-devel] re: PRoot: A Step Forward for QEMU User-Mode
Date: Mon, 21 Mar 2011 15:42:56 +0200	[thread overview]
Message-ID: <20110321134256.GA23734@afflict.kos.to> (raw)
In-Reply-To: <AANLkTinsiG4prSaXBs52kTM_1RQ4v_tieCnU42it_vhp@mail.gmail.com>

Hi,

First, thanks for the report!

On Mon, Mar 21, 2011 at 12:09:10PM +0000, Peter Maydell wrote:
> == Talk 11: PRoot: A Step Forward for QEMU User-Mode ==
> STMicroelectronics again, presenting an alternative to the usual
> "chroot plus binfmt_misc" approach for running target binaries
> seamlessly under qemu's linux-user mode.  It's a wrapper around qemu
> which uses ptrace to intercept the syscalls qemu makes to the host; in
> particular it can add the target-directory prefix to all filesystem
> access syscalls, and can turn an attempt to exec "/bin/ls" into an
> exec of "qemu-linux-arm /bin/ls". The advantage over chroot is that
> it's more flexible and doesn't need root access to set up. They didn't
> give figures for how much overhead the syscall interception adds,
> though.

Similar thing is done with scratchbox2, but with LD_PRELOAD instead of
ptrace. LD_PRELOAD for all around the corners (static binaries etc) and
the slowdown is major. ptrace would make at least the former problem
go away.

However, why do it behind Qemu's back anyway? In linux-user we already pass
most filesystem access via path() function. Any needed filesystem redirections
could be done there within Qemu itself.

Riku

  reply	other threads:[~2011-03-21 13:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-21 12:09 [Qemu-devel] Trip Report -- 1st QEMU Users Forum, Grenoble, 18 March 2011 Peter Maydell
2011-03-21 13:42 ` Riku Voipio [this message]
2011-03-22  8:22   ` [Qemu-devel] Re: PRoot: A Step Forward for QEMU User-Mode Cédric VINCENT

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=20110321134256.GA23734@afflict.kos.to \
    --to=riku.voipio@iki.fi \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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).