qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/4] target-mips: add "-semihosting-arg" option


From: Matthew Fortune
Subject: Re: [Qemu-devel] [PATCH 3/4] target-mips: add "-semihosting-arg" option and implement UHI Arg* ops
Date: Sun, 1 Mar 2015 22:39:33 +0000

> Add new command line option "-semihosting-arg". It is used for passing
> input arguments to the guest in semihosting mode. The option can be used
> multiple times. If n arguments are passed, then argument count
> (semihosting_argc) will be equal to n+1 as semihosting_argv[0] points at
> the program name. However, if no arguments are passed then argument
> count will be 0.

Is there any specific reason for not passing the name of the executable
even if no -semihosting-arg is present?

I think there are the following cases:

1) one or more -semihosting-arg options are given. So n+1 arguments are
   passed with the first one being kernel/boot name if available. The
   arguments are passed using UHI argc/argn operations (a0 == -1).
2) No -semihosting-arg options are given but the kernel/boot name is known.
   This could be passed either via the normal argument passing conventions
   that are already in place or via argc/argn operations.
3) No -semihosting arg options and unknown application name. For this you
   could again either do what is already done and pass kernel/append
   options or set a0=0 and indicate that there is no information at all.

I wonder if there should be some detection of using both -semihosting-arg
and -append? I think they are in direct conflict. It would probably be
good to have cases 2/3 above do the same as what happened before and
pass kernel name + append options. (By that I also mean setting up the
argv array directly and setting a0 to a positive value (2) rather than
using the new interface).

While it may not be used, this would theoretically allow a kernel to be
booted with -semihosting enabled, pass arguments in the same way they
always have and allow very early boot to emit messages using UHI. I.e.
the kernel will almost certainly never use the argc/argn/argnlen
interface.

I don't have any comments on the code except to say it looks to match
the spec for argc/argn/argnlen.

Thanks,
Matthew
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]