qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [kvm-devel] [PATCH] Add support for a configuration fil


From: Daniel P. Berrange
Subject: [Qemu-devel] Re: [kvm-devel] [PATCH] Add support for a configuration file
Date: Wed, 14 May 2008 00:20:21 +0100
User-agent: Mutt/1.4.1i

On Tue, May 13, 2008 at 06:07:08PM -0500, Anthony Liguori wrote:
> Anthony Liguori wrote:
> > I think this is pretty useful as-is.  I think it also gives us a reasonable
> > way to move forward that will keep everyone pretty happy.
> > 
> > Here's a short example:
> > 
> > qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
> > 
> > Would become `foo.qemu':
> > 
> >  # Main disk image
> >  hda=/home/anthony/images/linux.img
> > 
> >  # Redirect disk writes to a temporary image
> >  snapshot
> > 
> >  # Make the graphical display available on port 5902
> >  vnc=:2
> > 
> > With:
> > 
> > qemu-system-x86_64 -config foo.qemu
> 
> One thought I had, is that it would be very nice to break up the -drive 
> file=foo.img,if=scsi syntax within the config file.  In general, I'm 
> thinking something like:

Yes, that would be the main concern I have with the plain conversion
of existing command line args. It would essentially be limiting the 
expressiveness of the config file to that of the command line - flat
key,value pairs. All we'd be gaining  is avoidance of command line 
length limits and persistent storage. Two worthy goals, but IMHO it
could be worth striving for more structure, so the config can explicitly
represent arrays and hashes as concepts.

> [drive]
> file=foo.img
> if=scsi

This just feels like a bad 1/2 house compromise. Adds the complexity
of a more structured config file without giving the full benefits of
a more expressive format such as the 2 you show below.

> drive {
>    file=foo.img
>    if=scsi
> }

I like both this & the next format because they're very expressive.

> or even:
> 
> drive:
>    file=foo.img
>    if=scsi

That's very nearly YAML format[1], which is attractive because parsers
are available in every major programming language, and it is still
pretty human friendly.

So my preference would be to go with the last option and make sure
it really is YAML compliant so people can use standard tools for 
generating and parsing the format.

Regards,
Daniel

[1]  http://yaml.org/spec/1.2/
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

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