qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Paul Brook <paul@codesourcery.com>
Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file
Date: Wed, 14 May 2008 10:09:16 -0500	[thread overview]
Message-ID: <482B009C.2070101@us.ibm.com> (raw)
In-Reply-To: <200805141526.34293.paul@codesourcery.com>

Paul Brook wrote:
>> the "class" field is used to select the device model. Then all the other
>> parameters are used to initialize the device model. That way it is
>> possible to keep the compatibility with the existing options and add a
>> provision to instanciate arbitrary new device models, such as:
>>     
>
> I like the idea, but I'm not so keen on the automatic allocation. I generally 
> prefer explicit declaration over implicit things. The latter makes it very 
> easy to not notice when you make a typo.
>
> It sounds like what you really want is something similar to an OF device tree.  
> So you have something like:
>
> # pciide0 may be an alias (possibly provided by qemu)
> # e.g. pci0.slot1.func1.ide
> alias hda ide0.primary.master
>   

What I don't like about the ide0.primary.master syntax is that there 
isn't enough structure.  I would prefer:

alias hda ide,bus=0,primary,master

If you combine this with your magic variable idea, you could also do:

alias hda ide,bus=0,unit=$next

But you could also just fold that into Fabrice's syntax (which I prefer):

hda.class = ide,bus=0,unit=$next
hda.type = disk
hda.file = foo.img

If you then default bus, and unit, you can just write:

hda.class = ide
hda.type = disk
hda.file = foo.img

And better yet, you could even allow for something like:

hda.class = ide
hda.bus = 0
hda.unit = 0
hda.type = disk
hda.file = foo.img

So I really actually prefer Fabrice's syntax because there is much more 
structure.  I think it's a good idea to allow .class to contain multiple 
properties and to basically establish an alias.  This way, you could 
predefine a bunch of aliases for today's parameters like hda, hdb, etc.

> hda.type=disk
> hda.file=foo.img
>
> You can then define some form of magic aliases that select the next unused 
> device. e.g.
>
> alias mydrive $next_ide_disk
>
> IMHO This provides the flexibility and structure that Fabrice is talking 
> about, and with suitable aliases can be made to look a lot like the existing 
> options.
>
> This may require some internal restructuring to allow the machine descriptions 
> to feed into the user config file.
>   

I think if we choose a syntax we like, we can start using that pretty 
easily.  We'll have to start adjusting option names keeping them only 
valid on the command line (for things like -m).  However, I think it 
would grow pretty well into a machine description mechanism.

Regards,

Anthony Liguori

> Thoughts?
>
> Paul
>   

  parent reply	other threads:[~2008-05-14 15:09 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-13 21:19 [Qemu-devel] [PATCH] Add support for a configuration file Anthony Liguori
2008-05-13 23:07 ` [Qemu-devel] " Anthony Liguori
2008-05-13 23:20   ` [Qemu-devel] Re: [kvm-devel] " Daniel P. Berrange
2008-05-14  6:35     ` Colin Adams
2008-05-14 14:41     ` Avi Kivity
2008-05-14 14:52       ` Dor Laor
2008-05-14 15:02         ` Daniel P. Berrange
2008-05-14 15:18         ` [kvm-devel] [Qemu-devel] " Anthony Liguori
2008-05-14 14:59       ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2008-05-14 15:10       ` Andreas Färber
2008-05-15 14:50         ` Ian Jackson
2008-05-14  8:27   ` [Qemu-devel] " Fabrice Bellard
2008-05-14 10:31     ` Avi Kivity
2008-05-14 12:26       ` Fabrice Bellard
2008-05-14 13:31         ` [kvm-devel] " Daniel P. Berrange
2008-05-15  8:04           ` Avi Kivity
2008-05-15 11:52             ` Daniel P. Berrange
2008-05-15 12:04               ` Avi Kivity
2008-05-15 12:16                 ` Andreas Färber
2008-05-15 12:20                 ` Laurent Vivier
2008-05-14 14:06         ` Anthony Liguori
2008-05-14 14:26         ` Paul Brook
2008-05-14 14:45           ` [kvm-devel] " Javier Guerra
2008-05-14 15:13             ` Johannes Schindelin
2008-05-14 15:30               ` Javier Guerra
2008-05-14 15:37                 ` Johannes Schindelin
2008-05-14 15:42                   ` Javier Guerra
2008-05-14 16:07                   ` Kelly French
2008-05-15 14:59                     ` Paul Brook
2008-05-14 16:01                 ` Andreas Färber
2008-05-14 16:21                   ` Daniel P. Berrange
2008-05-14 16:37                     ` Andreas Färber
2008-05-14 16:29               ` Fabrice Bellard
2008-05-17 21:49                 ` Luca Barbato
2008-05-14 15:22             ` Daniel P. Berrange
2008-05-14 15:09           ` Anthony Liguori [this message]
2008-05-14 15:18             ` Paul Brook
2008-05-14 16:25           ` Fabrice Bellard
2008-05-14 14:36   ` andrzej zaborowski
2008-05-14 15:10     ` Johannes Schindelin
2008-05-15 14:58     ` Ian Jackson
2008-05-15 12:03 ` [Qemu-devel] " Erik de Castro Lopo
2008-05-15 12:36   ` andrzej zaborowski
2008-05-15 13:22     ` Daniel P. Berrange
2008-05-15 14:46       ` andrzej zaborowski
2008-05-15 15:05   ` Anthony Liguori
2008-05-15 15:26     ` Avi Kivity
2008-05-15 18:50       ` Anthony Liguori

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=482B009C.2070101@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).