On 05/26/2017 08:36 AM, Peter Krempa wrote:
> On Fri, May 26, 2017 at 08:22:26 -0400, John Ferlan wrote:
>>
>>
>> On 05/26/2017 03:14 AM, Peter Krempa wrote:
>>> On Thu, May 25, 2017 at 15:57:01 -0400, John Ferlan wrote:
>>>> In order to ensure that whenever something is added to virNodeDevCapType
>>>> that both functions are considered for processing of a new capability,
>>>> change the if-then-else construct into a switch statement.
>>>>
>>>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
>>>> ---
>>>> src/conf/virnodedeviceobj.c | 80 +++++++++++++++++++++++++++++++++------------
>>>> 1 file changed, 60 insertions(+), 20 deletions(-)
>>>>
>>>> diff --git a/src/conf/virnodedeviceobj.c b/src/conf/virnodedeviceobj.c
>>>> index bbb6eeb..913cdda 100644
>>>> --- a/src/conf/virnodedeviceobj.c
>>>> +++ b/src/conf/virnodedeviceobj.c
>>>> @@ -48,19 +48,41 @@ virNodeDeviceObjHasCap(const virNodeDeviceObj *dev,
>>>> while (caps) {
>>>> if (STREQ(cap, virNodeDevCapTypeToString(caps->data.type))) {
>>>> return 1;
>>>> - } else if (caps->data.type == VIR_NODE_DEV_CAP_SCSI_HOST) {
>>>> - if ((STREQ(cap, fc_host_cap) &&
>>>> - (caps->data.scsi_host.flags &
>>>> - VIR_NODE_DEV_CAP_FLAG_HBA_FC_HOST)) ||
>>>> - (STREQ(cap, vports_cap) &&
>>>> - (caps->data.scsi_host.flags &
>>>> - VIR_NODE_DEV_CAP_FLAG_HBA_VPORT_OPS)))
>>>> - return 1;
>>>> - } else if (caps->data.type == VIR_NODE_DEV_CAP_PCI_DEV) {
>>>> - if ((STREQ(cap, mdev_types)) &&
>>>> - (caps->data.pci_dev.flags &
>>>> - VIR_NODE_DEV_CAP_FLAG_PCI_MDEV))
>>>> - return 1;
>>>> + } else {
>>>> + switch (caps->data.type) {
>>>> + case VIR_NODE_DEV_CAP_PCI_DEV:
>>>> + if ((STREQ(cap, mdev_types)) &&
>>>> + (caps->data.pci_dev.flags &
>>>> + VIR_NODE_DEV_CAP_FLAG_PCI_MDEV))
>>>
>>> Since you are touching this, put this on a single line. It looks very
>>> ugly this way. It also fits into the 80 col boundary, so I don't see a
>>> reaosn for this.
>>
>> For MDEV - it can fit, for SCSI_HOST, not as clean, but it could be:
>>
>> if ((STREQ(cap, fc_host_cap) && (caps->data.scsi_host.flags &
>> VIR_NODE_DEV_CAP_FLAG_HBA_FC_HOST)) ||
>> (STREQ(cap, vports_cap) && (caps->data.scsi_host.flags &
>> VIR_NODE_DEV_CAP_FLAG_HBA_VPORT_OPS)))
>
> That is WAY worse. The binary mask should be on a single line since it's
> semantically connected.
I don't disagree! I wouldn't take that route, but it keeps everything
inside 80 cols...
>
> Also the 80 col rule is not really strict. Especially if it hinders
> readability of the code. The above suggestion is a very good example
> where you'd completely destroy readability.
I'll just go beyond the 80 cols. I personally don't like that, but
that's just a personal preference thing and readability wise it's I
think better than the multiline condition just because of 80 cols.
Tks -
John
>
>
>> return 1;
>>
>> Although I'm not sure I like the way that looks.
>
> [...]
>
>>
>> But does that "violate" the too many changes at once "guideline"?
>
> If you feel so, leave it as-is.
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
