param format about qeme extra options parse in

param format about qeme extra options parse in

[Ke, Liping]

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)


How do you think of it? All extra options are given within "" as one parameter.

Thanks& Regards,
criping

Re: param format about qeme extra options parse in

[Scott Garman]

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)
>
>
> How do you think of it? All extra options are given within "" as one
> parameter.

Sounds reasonable to me.

Scott

-- 
Scott Garman
Embedded Linux Distro Engineer - Yocto Project

Re: param format about qeme extra options parse in

[Saul Wold]

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

Re: param format about qeme extra options parse in

[Zhang, Jessica]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

Saul Wold wrote:
> 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!

Yes, it just a plain text in the GUI, that's on purpose to off-load our
responsibilitie to testing all the fields if we list them individually in
the GUI, which means we'll tested out all the combinations.  By saying that,
I still advise Liping while on the task, don't just plainly passing in the
text that user specified.  If you look at poky-qemu-internal, you'll see
there're certain things setting there for different architectures, so I'd
expect to some level of checking to ensure there's no conflict between what
user passing in and what already setted in the script or at least generate
some warning...

- Jessica
> 
>> 
>> 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

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 8455 bytes --]

Re: param format about qeme extra options parse in

[Ke, Liping]

Thanks scott!
I will send you the patch for review after I add the extra parameter.

Thanks & Regards,
criping

> -----Original Message-----
> From: Garman, Scott A
> Sent: Tuesday, December 07, 2010 5:04 PM
> To: Ke, Liping
> Cc: Zhang, Jessica; Lu, Lianhao; yocto@yoctoproject.org
> Subject: Re: param format about qeme extra options parse in
> 
> 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)
> >
> >
> > How do you think of it? All extra options are given within "" as one
> > parameter.
> 
> Sounds reasonable to me.
> 
> Scott
> 
> --
> Scott Garman
> Embedded Linux Distro Engineer - Yocto Project