| Message ID | 1441863827-4004-1-git-send-email-gang.chen.5i5j@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 2015年09月10日 13:43, gang.chen.5i5j@gmail.com wrote: > From: Chen Gang <gang.chen.5i5j@gmail.com> > > If qemu sets interp_prfix via command line '-L' instead of environments > variable QEMU_LD_PREFIX, it will cause syscall execve() failed. Because > the 2nd qemu has no command line '-L'. > Oh, sorry for typo, "the 2nd" -> "the second". > So qemu need always set QEMU_LD_PREFIX when interp_prefix is changed. > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Thanks.
On 10 September 2015 at 06:43, <gang.chen.5i5j@gmail.com> wrote: > From: Chen Gang <gang.chen.5i5j@gmail.com> > > If qemu sets interp_prfix via command line '-L' instead of environments > variable QEMU_LD_PREFIX, it will cause syscall execve() failed. Because > the 2nd qemu has no command line '-L'. > > So qemu need always set QEMU_LD_PREFIX when interp_prefix is changed. I think this is user error. If you want exec to work automatically onto a second QEMU then you need to set up binfmt misc with a wrapper and probably the environment variables. I don't think we need to turn all our command line switches into environment variables: they're not supposed to be somehow magically inherited by child QEMU processes. thanks -- PMM
From: peter.maydell@linaro.org > Date: Thu, 10 Sep 2015 10:02:27 +0100 > > On 10 September 2015 at 06:43, <gang.chen.5i5j@gmail.com> wrote: >> From: Chen Gang <gang.chen.5i5j@gmail.com> >> >> If qemu sets interp_prfix via command line '-L' instead of environments >> variable QEMU_LD_PREFIX, it will cause syscall execve() failed. Because >> the 2nd qemu has no command line '-L'. >> >> So qemu need always set QEMU_LD_PREFIX when interp_prefix is changed. > > I think this is user error. If you want exec to work automatically > onto a second QEMU then you need to set up binfmt misc with a > wrapper and probably the environment variables. I don't > think we need to turn all our command line switches into > environment variables: they're not supposed to be somehow > magically inherited by child QEMU processes. > For me, when users type a command line under Linux shell, they always assume all related executions will know about their commands, they need not set the environments again (at least, in one process, they assume so). execve() will not change the pid, so the users will 'feel': they are using only one process. I guess all 'users' will support me (this patch will let them a little easier). ;-) Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
On 10 September 2015 at 10:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote: > From: peter.maydell@linaro.org >> Date: Thu, 10 Sep 2015 10:02:27 +0100 >> >> On 10 September 2015 at 06:43, <gang.chen.5i5j@gmail.com> wrote: >>> From: Chen Gang <gang.chen.5i5j@gmail.com> >>> >>> If qemu sets interp_prfix via command line '-L' instead of environments >>> variable QEMU_LD_PREFIX, it will cause syscall execve() failed. Because >>> the 2nd qemu has no command line '-L'. >>> >>> So qemu need always set QEMU_LD_PREFIX when interp_prefix is changed. >> >> I think this is user error. If you want exec to work automatically >> onto a second QEMU then you need to set up binfmt misc with a >> wrapper and probably the environment variables. I don't >> think we need to turn all our command line switches into >> environment variables: they're not supposed to be somehow >> magically inherited by child QEMU processes. >> > > For me, when users type a command line under Linux shell, they always > assume all related executions will know about their commands, they need > not set the environments again (at least, in one process, they assume so). > > execve() will not change the pid, so the users will 'feel': they are using only > one process. But execve won't do the right thing if it's another target binary, unless you've set up binfmt_misc. And if you're setting up binfmt_misc then (a) you should just do it right and (b) you wouldn't have been directly running QEMU with command line arguments in the first place. I really don't think we need to change anything here. thanks -- PMM
On 9/10/15 20:35, Peter Maydell wrote: > On 10 September 2015 at 10:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote: >> >> For me, when users type a command line under Linux shell, they always >> assume all related executions will know about their commands, they need >> not set the environments again (at least, in one process, they assume so). >> >> execve() will not change the pid, so the users will 'feel': they are using only >> one process. > > But execve won't do the right thing if it's another target binary, > unless you've set up binfmt_misc. And if you're setting up > binfmt_misc then (a) you should just do it right and (b) you > wouldn't have been directly running QEMU with command line > arguments in the first place. > Yes, we have to use binfmt_misc to let execve() run correctly. After let execve() run correctly, I am analyzing another issue when let qemu run wine (it is a pending issue, I guess, it is related with mmu). At present, I often change the input parameters (e.g. -strace, -d ...), if we let a qemu process itself always know about its input parameters, it will be really useful. For qemu, I still feel that we need notice about the mismatch between env variables and input parameters. - If we are sure the input parameters are only for one normal process, we need not care about the mismatch between env variables and input parameters (I guess, most of programs need not care about it). - But if we have to process the un-normal process (e.g. our qemu), we have to notice about the mismatch between evn variables and input parameters. Or command line users may meet various strange things. - Since we provide the command line options, we have to always let them be correct within one normal or un-normal process. Thanks
On 10 September 2015 at 16:15, Chen Gang <xili_gchen_5257@hotmail.com> wrote: > Yes, we have to use binfmt_misc to let execve() run correctly. After > let execve() run correctly, I am analyzing another issue when let qemu > run wine (it is a pending issue, I guess, it is related with mmu). > > At present, I often change the input parameters (e.g. -strace, -d ...), > if we let a qemu process itself always know about its input parameters, > it will be really useful. If you want settings to apply to all child qemu processes, use the environment variables... that is one of the things they are for. > For qemu, I still feel that we need notice about the mismatch between > env variables and input parameters. > > - If we are sure the input parameters are only for one normal process, > we need not care about the mismatch between env variables and input > parameters (I guess, most of programs need not care about it). > > - But if we have to process the un-normal process (e.g. our qemu), we > have to notice about the mismatch between evn variables and input > parameters. Or command line users may meet various strange things. > > - Since we provide the command line options, we have to always let them > be correct within one normal or un-normal process. I think it would be unexpected behaviour for command line arguments provided to one QEMU program to affect the execution of a different QEMU process. thanks -- PMM
On 9/10/15 23:24, Peter Maydell wrote: > On 10 September 2015 at 16:15, Chen Gang <xili_gchen_5257@hotmail.com> wrote: >> Yes, we have to use binfmt_misc to let execve() run correctly. After >> let execve() run correctly, I am analyzing another issue when let qemu >> run wine (it is a pending issue, I guess, it is related with mmu). >> >> At present, I often change the input parameters (e.g. -strace, -d ...), >> if we let a qemu process itself always know about its input parameters, >> it will be really useful. > > If you want settings to apply to all child qemu processes, use the > environment variables... that is one of the things they are for. > Yes it will be work well. :-) >> For qemu, I still feel that we need notice about the mismatch between >> env variables and input parameters. >> >> - If we are sure the input parameters are only for one normal process, >> we need not care about the mismatch between env variables and input >> parameters (I guess, most of programs need not care about it). >> >> - But if we have to process the un-normal process (e.g. our qemu), we >> have to notice about the mismatch between evn variables and input >> parameters. Or command line users may meet various strange things. >> >> - Since we provide the command line options, we have to always let them >> be correct within one normal or un-normal process. > > I think it would be unexpected behaviour for command line arguments > provided to one QEMU program to affect the execution of a different > QEMU process. > For me, I guess, it should be still OK: - For execve(), the input parameters should always have effect with ( since we treate it as one un-normal process). - For other QEMU cases (really different QEMU child processes). If they have their own command line options, the will override the env variables which may be set by original command line parameters. If they have no their own command line options, they need inherit the parent QEMU process's command line options (e.g. -strace, -d ...). Thanks.
diff --git a/linux-user/main.c b/linux-user/main.c index 06dd296..2f31ea6 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -3539,7 +3539,11 @@ static void handle_arg_stack_size(const char *arg) static void handle_arg_ld_prefix(const char *arg) { + char *buf = g_strdup_printf("QEMU_LD_PREFIX=%s", arg); + interp_prefix = strdup(arg); + (void) envlist_setenv(envlist, buf); + g_free(buf); } static void handle_arg_pagesize(const char *arg)