This patch is for qemu itself.
It test AT_FLAGS and determine whether it is start by binfmt_misc and
whether P flag is used.
** Patch added: "preserve-argv0.patch"
https://bugs.launchpad.net/qemu/+bug/1818483/+attachment/5252630/+files/preserve-argv0.patch
--
You received this bug
This patch is for linux kernel.
It will set the 3rd bit of AT_FLAGS, if P is set for binfmt_misc.
The major concern is that AT_FLAGS is never used, then, should we use it
here?
** Patch added: "binfmt_preserve_argv0.patch"
@Peter Luyou and me are working on try to pass the info about whether P
flag is enabled or not by enviroment var or auxval. While we have not
found the right method to do it from binfmt_misc.
In fact, currently qemu trys to process the O flag, and it cannot work at all.
When you install
hi Peter:
You are right, any additional modification should not affect the previous.
We expect that if this issue could be resolved without code change it's the
best.
it may need to modify both binfmt_misc side to pass more information for flag P
and qemu side to handle it.
--
You received
The question is: can we have one set of QEMU code that copes correctly
with both 'binfmt_misc with P flag' and 'binfmt_misc without P flag' ?
Your patch makes -P work but breaks some cases without it. That means
it's not backwards compatible with all the existing QEMU installations
and use cases
hi Peter:
Thanks for your suggestion.
but anyway we have to modify qemu code when binfmt_misc passes argv[0] in,
right?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1818483
Title:
qemu user mode
Doesn't doing the check like that break execution of a command like
"echo 'MISC_FMT_PRESERVE_ARGV0'" in a chroot environment that isn't
using -P ?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
