On Thu, Jun 25, 2015 at 11:46:41AM +0200, Ján Tomko wrote:
On Thu, Jun 25, 2015 at 08:44:17AM +0200, Martin Kletzander wrote:On Wed, Jun 24, 2015 at 12:04:33PM -0400, Laine Stump wrote: >At this point you can see that it all comes down to what name we want to >give the subelement; within that, we give the exact name of the qemu >device, and the exact name/value of any qemu options that we set to >non-default values. > >Somebody *please* have an opinion on the name for this, because none of >these strikes me as better or worse (well, I think I dislike <driver> >To be honest, I kinds dislike all of them. Not that they would be chosen poorly, no, it's simply because the good sensible choice is unavailable due to another poor decision in the past (this may be another point for Michal's talk on KVM Forum). Thinking about it I must say I don't like how target (which is supposed to match a place where the device appears for the guest) is used for the model specification, on the other hand (ab)using 'model' element for the specification of an "address" in guest (that's what I understand chassis and port are) doesn't feel any better. What if we go with two of those elements? Would that be too much pain? E.g.: <controller type='pci model='pci-root-port' index='3'> <address type='pci' bus='0' slot='4' function='1'> <model type='ioh3420'/> <target chassis='3' port='0x21'/> </controller>I like this, essentially a subModel without the camelCase. One small nit: <model name='ioh4320'/> would look nicer to me, but we're using <model type=/> in at least one other place, so I'm fine with both.
I didn't think about the 'type', I probably just typed it in there because each line had a 'type' already in :) I like 'name' better too, but diving deeply into it, I have no strong opinions on that.
JanI understand this might look like an overkill, but I think it's better safe then sorry, I guess I just see us not so far in the future regretting any decision made now.
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
