Re: [PATCH 2/2] IFC VDPA layer

[Zhu Lingshan <lingshan.zhu@linux.intel.com>]

Hello Mark,

Thanks for your comments, I will change the lines in next patchset.

Thanks,
BR
Zhu Lingshan
On 11/10/2019 3:56 AM, Mark D Rustad wrote:
> On Nov 5, 2019, at 1:37 AM, Zhu Lingshan <lingshan.zhu@intel.com> wrote:
>
>> This commit introduced IFC operations for vdpa, which complys to
>> virtio_mdev and vhost_mdev interfaces, handles IFC VF
>> initialization, configuration and removal.
>>
>> Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
>> ---
>>  drivers/vhost/ifcvf/ifcvf_main.c | 605 
>> +++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 605 insertions(+)
>>  create mode 100644 drivers/vhost/ifcvf/ifcvf_main.c
>>
>> diff --git a/drivers/vhost/ifcvf/ifcvf_main.c 
>> b/drivers/vhost/ifcvf/ifcvf_main.c
>> new file mode 100644
>> index 0000000..7165457
>> --- /dev/null
>> +++ b/drivers/vhost/ifcvf/ifcvf_main.c
>> @@ -0,0 +1,605 @@
>
> <snip>
>
>> +    for (i = 0; i < IFCVF_MAX_QUEUE_PAIRS * 2; i++) {
>> +        if (!vf->vring[i].ready) {
>> +            IFC_ERR(ifcvf->dev,
>> +                "Failed to start datapath, vring %d not ready.\n", i);
>> +            return -EINVAL;
>> +        }
>> +
>> +        if (!vf->vring[i].size) {
>> +            IFC_ERR(ifcvf->dev,
>> +                "Failed to start datapath, vring %d size is 
>> zero.\n", i);
>> +            return -EINVAL;
>> +        }
>> +
>> +        if (!vf->vring[i].desc || !vf->vring[i].avail ||
>> +            !vf->vring[i].used) {
>> +            IFC_ERR(ifcvf->dev,
>> +                "Failed to start datapath, "
>> +                "invaild value for vring %d desc,"
>> +                "avail_idx or usex_idx.\n", i);
>
> Please don't break up the format string. Start it on the second line 
> and let it run as long as it needs to. Also you will find that it is 
> improperly spaced as it is. It makes it easier to grep the source to 
> find the source of a message. The coding style has an explicit 
> exception for such long lines for this reason.
>
> Also, please don't put .'s on the end of log messages. It serves no 
> purpose and just adds to the log, the binary size and the source size. 
> There are quite a few of these.
>
> <snip>
>
> -- 
> Mark Rustad, MRustad@gmail.com