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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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
>   


-------------------------------------------------------------------------
 
 

_______________________________________________
kvm-devel mailing list
kvm-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/kvm-devel