Réf. : Re: [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

Réf. : Re: [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[laurent.vivier-6ktuUTfB/bM]

Hi Anthony,

I think passing only the directory name is better because it can be like a
"black box" : the user don't have to know how it is inside. And it is much
more simple to use "qemu my_pc" than "qemu -c my_pc/config".

Regards,
Laurent

------------------------------------------------------
      Pour :      Jorge Lucángeli Obes <t4m5yn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
      cc :  kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
      ccc :
      Objet :     Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly
execute a directory (and storing command line options in it)
Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
Envoyé par : kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
31/08/2007 13:54 EST
            <font size=-1></font>



















It makes little sense to pass a directory when you can pass a config
file and assume that the directory the config file is in is the CWD.

For instance, if vm.cfg contained just the command line arguments, you
could have:

MyImage/vm.cfg:        -hda disk0.qcow -m 512
MyImage/disk0.qcow:    <disk image>

And then do:

qemu -c MyImage/vm.cfg







-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Réf. : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Johannes Schindelin]

Hi,

On Fri, 31 Aug 2007, laurent.vivier@bull.net wrote:

> I think passing only the directory name is better because it can be like 
> a "black box" : the user don't have to know how it is inside.

I consider this a super downside.

"If you think your users are idiots, only idiots will use it [your 
software]."

> And it is much more simple to use "qemu my_pc" than "qemu -c 
> my_pc/config".

_Much_ more simple?  Not really.

Having said that, it should not be a big problem to change the source just 
for _you_, so that if "my_pc" could not be opened, it automatically tries 
"my_pc/config".  Trivial.

Ciao,
Dscho

Re: [Qemu-devel] Réf. : Re: [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Avi Kivity]

Johannes Schindelin wrote:
>   
>> I think passing only the directory name is better because it can be like 
>> a "black box" : the user don't have to know how it is inside.
>>     
>
> I consider this a super downside.
>
> "If you think your users are idiots, only idiots will use it [your 
> software]."
>   

I don't consider myself an idiot, yet I get annoyed when software forces 
me to learn its implementation details.


-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [Qemu-devel] Réf. : Re: [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Johannes Schindelin]

Hi,

On Sat, 1 Sep 2007, Avi Kivity wrote:

> Johannes Schindelin wrote:
> >   
> > > I think passing only the directory name is better because it can be like
> > > a "black box" : the user don't have to know how it is inside.
> > >     
> > 
> > I consider this a super downside.
> > 
> > "If you think your users are idiots, only idiots will use it [your
> > software]."
> >   
> 
> I don't consider myself an idiot, yet I get annoyed when software forces me
> to learn its implementation details.

Maybe you missed my point.

If the user executes "qemu -c bla/config", she might get interested in 
looking at that file, and find out that it is easy to modify.  That is 
definitely a benefit worth having.

Ciao,
Dscho


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Réf. : Re: [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Anthony Liguori]

On Fri, 2007-08-31 at 22:13 +0200, laurent.vivier@bull.net wrote:
> Hi Anthony,
> 
> I think passing only the directory name is better because it can be like a
> "black box" : the user don't have to know how it is inside. And it is much
> more simple to use "qemu my_pc" than "qemu -c my_pc/config".

You're overriding what "qemu my_pc" means.  "qemu my_pc" create a QEMU
vm with 128m of memory and -hda my_pc with the default network card.

"qemu -c my_pc/config" only has one meaning: read command line arguments
from "my_pc/config".

Your suggested syntax may be simpler for your particular use-case, but
it makes QEMU much more difficult to understand for every other user.

Regards,

Anthony Liguori

> Regards,
> Laurent
> 
> ------------------------------------------------------
>       Pour :      Jorge Lucángeli Obes <t4m5yn@gmail.com>
>       cc :  kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org
>       ccc :
>       Objet :     Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly
> execute a directory (and storing command line options in it)
> Anthony Liguori <anthony@codemonkey.ws>
> Envoyé par : kvm-devel-bounces@lists.sourceforge.net
> 31/08/2007 13:54 EST
>             <font size=-1></font>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> It makes little sense to pass a directory when you can pass a config
> file and assume that the directory the config file is in is the CWD.
> 
> For instance, if vm.cfg contained just the command line arguments, you
> could have:
> 
> MyImage/vm.cfg:        -hda disk0.qcow -m 512
> MyImage/disk0.qcow:    <disk image>
> 
> And then do:
> 
> qemu -c MyImage/vm.cfg
> 
> 
> 
> 
> 
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Re: Réf. : Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Laurent Vivier]

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

Anthony Liguori wrote:
> On Fri, 2007-08-31 at 22:13 +0200, laurent.vivier@bull.net wrote:
>> Hi Anthony,
>>
>> I think passing only the directory name is better because it can be like a
>> "black box" : the user don't have to know how it is inside. And it is much
>> more simple to use "qemu my_pc" than "qemu -c my_pc/config".
> 
> You're overriding what "qemu my_pc" means.  "qemu my_pc" create a QEMU
> vm with 128m of memory and -hda my_pc with the default network card.
> 
> "qemu -c my_pc/config" only has one meaning: read command line arguments
> from "my_pc/config".
> 
> Your suggested syntax may be simpler for your particular use-case, but
> it makes QEMU much more difficult to understand for every other user.

I don't totally agree with you: "qemu my_pc", when my_pc is a file, as you
explain, has an implicit behavior "use vm with 128 MB and hda my_pc and the
default network card", so perhaps we can have also "qemu my_pc", when my_pc is a
directory, has an implicit behavior "use vm as defined in my_pc/config and hd
found in this directory".

BUT, as there is a lot of debates on this, I AGREE WITH YOU: we should choose
the most simple, logic and common solution... and "-c" seems the good one.

Jorge made a very good work, it should be sad to not use it.

Regards,
Laurent
-- 
------------- Laurent.Vivier@bull.net  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Réf. : Re: [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[Daniel P. Berrange]

On Fri, Aug 31, 2007 at 10:13:11PM +0200, laurent.vivier-6ktuUTfB/bM@public.gmane.org wrote:
> I think passing only the directory name is better because it can be like a
> "black box" : the user don't have to know how it is inside. And it is much
> more simple to use "qemu my_pc" than "qemu -c my_pc/config".

If you need this incredible 'simplicity', a 1 line shell script can easily
provide it for you;

    $ cat myqemu
    #!/bin/sh
    exec qemu -c $1/config

One of the great strengths of QEMU is its predictability - it may have a
huge number of command line args, but this is exactly what gives QEMU such
power & utility. It makes it very straightforward to build applications
around QEMU, and ensure it behaviours in a 100% reliable & predictable manner.
We should be wary of putting policy & heuristics into QEMU to turn it into
a 'black box' because that will compromise the use cases at which it currently
excels. A simple '-c' arg which takes a path to a config file is more than
sufficient, without needing heuristics to look for magical named files in
directories.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/