From: Saul Wold <sgw@linux.intel.com>
To: "Ke, Liping" <liping.ke@intel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>,
"Garman, Scott A" <scott.a.garman@intel.com>
Subject: Re: param format about qeme extra options parse in
Date: Tue, 07 Dec 2010 08:30:05 -0800 [thread overview]
Message-ID: <4CFE610D.7030008@linux.intel.com> (raw)
In-Reply-To: <789F9655DD1B8F43B48D77C5D30659733104C7B4@shsmsx501.ccr.corp.intel.com>
On 12/06/2010 11:29 PM, Ke, Liping wrote:
> Hi, Jessica& Scott
>
> I am now looking@the task of User specified qemu config support, desc " We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake"
>
>
> Currently, for the user experiences, the param parsing is without specific ordering. So the parsing shell code would be somewhat fixed. Since we're needing to append other user options directly, the options vary greatly. So my plan is all user options are put into "" and read in as one parameters for easier processing in the shell script, for example:
>
> ./poky-qemu qemuarm qemuarm.bin unfs_dir serial "-smp -hda /dev/myfda_file -m 256" (extra options for advance user)
>
So is this just going to be a text field in the GUI? Will there be any
sanity checking of the paramerters? Or they are just passed directly
and qemu can blow up if bad parameters are passed?
Sau!
>
> How do you think of it? All extra options are given within "" as one parameter.
>
> Thanks& Regards,
> criping
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
next prev parent reply other threads:[~2010-12-07 16:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 7:29 param format about qeme extra options parse in Ke, Liping
2010-12-07 9:04 ` Scott Garman
2010-12-08 1:46 ` Ke, Liping
2010-12-07 16:30 ` Saul Wold [this message]
2010-12-07 17:09 ` Zhang, Jessica
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=4CFE610D.7030008@linux.intel.com \
--to=sgw@linux.intel.com \
--cc=liping.ke@intel.com \
--cc=scott.a.garman@intel.com \
--cc=yocto@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.