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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list