[dpdk-dev] [PATCH 7/9] pci: add a helper for device name

David Marchand david.marchand at 6wind.com
Wed Feb 10 13:04:16 CET 2016


On Wed, Feb 10, 2016 at 12:10 PM, Jan Viktorin <viktorin at rehivetech.com> wrote:
> On Fri, 29 Jan 2016 15:08:34 +0100
> David Marchand <david.marchand at 6wind.com> wrote:
>
>> eal is a better place than ethdev for naming resources.
>> Add a helper here, and make use of it in ethdev hotplug code.
>>
>> Signed-off-by: David Marchand <david.marchand at 6wind.com>
>> ---
>>  lib/librte_eal/common/include/rte_pci.h | 28 ++++++++++++++++++++++++++++
>>  lib/librte_ether/rte_ethdev.c           | 22 ++--------------------
>>  2 files changed, 30 insertions(+), 20 deletions(-)
>>
>> diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
>> index 334c12e..9edd5f5 100644
>> --- a/lib/librte_eal/common/include/rte_pci.h
>> +++ b/lib/librte_eal/common/include/rte_pci.h
>> @@ -309,6 +309,34 @@ eal_parse_pci_DomBDF(const char *input, struct rte_pci_addr *dev_addr)
>>  }
>>  #undef GET_PCIADDR_FIELD
>>
>> +/**
>> + * Utility function to write a pci device name, this device name can later be
>> + * used to retrieve the corresponding rte_pci_addr using above functions.
>> + *
>> + * @param addr
>> + *   The PCI Bus-Device-Function address
>> + * @param output
>> + *   The output buffer string
>> + * @param size
>> + *   The output buffer size
>> + * @return
>> + *  0 on success, negative on error.
>> + */
>> +static inline int
>> +eal_pci_device_name(const struct rte_pci_addr *addr,
>> +                 char *output, int size)
>
> "size_t size" (or unsigned int) seems to be better to me.

Yes.

>
>> +{
>> +     int ret;
>> +
>> +     ret = snprintf(output, size, PCI_PRI_FMT,
>> +                    addr->domain, addr->bus,
>> +                    addr->devid, addr->function);
>> +     if (ret < 0 || ret >= size)
>> +             return -1;
>
> The return value is not checked (below). I think, such functions
> are usually missing error checking as nobody expects them to fail.
> Wouldn't it be better to panic here?

assert or panic, yes.


-- 
David Marchand


More information about the dev mailing list