[libvirt] [PATCH] rng: tighten up domain <controller> schema

Osier Yang jyang at redhat.com
Thu Apr 18 11:27:28 UTC 2013


On 18/04/13 19:16, Laine Stump wrote:
> On 04/18/2013 05:41 AM, Martin Kletzander wrote:
>> On 04/18/2013 11:05 AM, Osier Yang wrote:
>>> On 18/04/13 17:00, Martin Kletzander wrote:
>>>> On 04/18/2013 10:54 AM, Osier Yang wrote:
>>>>> On 18/04/13 16:42, Martin Kletzander wrote:
>>>>>> On 04/18/2013 06:36 AM, Laine Stump wrote:
>>>>>>> The rng schema for <controller> had been non-specific about which
>>>>>>> types of controllers allowed which models, and also allowed the
>>>>>>> num_queues attribute (since that hasn't been released yet, should we
>>>>>>> rename it to "numQueues"?)
>>>>>> Since there's still time (the commit with that is
>>>>>> v1.0.4-65-gd4bf0a9), I
>>>>>> think we should rename it ASAP since we are using camelCase for all the
>>>>>> attribute names.
>>>>>>
>>>>>> Apart from that, the RNG with this patch is precise according to the
>>>>>> documentation, so ACK.  I'll try to send the numQueues patch to see
>>>>>> what
>>>>>> others think.
>>>>> I guess you mean multiple queues support for virtio network?
>>>>> Regardless of which style we will use finally, FYI,  "num_queues" is
>>>>> used for disk.. Personally I'm fine with either, because we already
>>>>> use both across.
>>>>>
>>>> Yes, I meant the virtio-scsi num_queues.  As we're trying not to use
>>>> underscores in XML, I hope we can still switch it.  I haven't found any
>>>> other num_queues anywhere in the code.  Could you point me to the commit
>>>> that uses that?  I'm sending the previously discussed patch in the
>>>> meantime.
>>>>
>>> Except the virtio-scsi num_queues, there is no other tag for multiple
>>> queue yet, we will need a patch to support multiple queue for the network,
>>> but it's not committed yet.
>>>
>>> It's fine to convert it now, 1.0.5 is not released yet. But is it
>>> deserved to
>>> do, we already have many tags with underscore, which can't be changed
>>> for back-compat.
>>>
>> I believe those attributes [1] were created by mistake, and kept only
>> because of backward compatibility.  I'm trying to be open-minded,
>> though, so I'm not forcing my patch in, but seeing it just as a
>> proposal.  Others may have different opinions and I'm willing to discuss
>> that.  My first feeling, though, was that we should try to keep the same
>> policy for as many of them as possible.  OTOH, I've mistaken the
>> underscore with a hyphen when I remembered what Daniel told me about
>> attributes [2].
> I had recalled DV saying something about underscores in the names a long
> time ago, and I recently asked about underscore vs. camelCase, and danpb
> said the same thing. (Personally I don't have a preference one way or
> the other, but if we really are trying to avoid them, now is our chance).

I'm fine with either keeping it or changing num_queues. For long
term consistence, I agreed with having a consistent naming style
is nice.

>
> In the meantime, in other device types, we've tried to keep backend
> details like this pushed into a <driver> subelement when possible, to
> avoid polluting the main element (e.g. see the <driver> subelement of
> <interface>). Is it worth putting this numQueues attribute in a <driver>
> subelement too? Or am I just playing XML God?

Not sure if you mean the upcoming numQueues for interface. But for the
existing num_queues, it's for the virtio-scsi controller, putting it in 
<driver>
doesn't reflect the purpose.

>
> (sorry for not bringing all this up when the patches were originally
> posted - it's just become impossible for me to even open all the
> messages on the list, much less read and understand them :-/)
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list




More information about the libvir-list mailing list