[dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
Burakov, Anatoly
anatoly.burakov at intel.com
Tue Feb 13 15:25:31 CET 2018
On 13-Feb-18 2:16 PM, Van Haaren, Harry wrote:
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>> Sent: Tuesday, February 13, 2018 1:51 PM
>> To: Burakov, Anatoly <anatoly.burakov at intel.com>
>> Cc: dev at dpdk.org; Tan, Jianfeng <jianfeng.tan at intel.com>
>> Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
>>
>>>> rte_errno values should not be negative.
>>>>
>>>> Fixes: bacaa2754017 ("eal: add channel for multi-process communication")
>>>> Fixes: 783b6e54971d ("eal: add synchronous multi-process communication")
>>>> Cc: jianfeng.tan at intel.com
>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
>>>
>>> Reviewed-by: Jianfeng Tan <jianfeng.tan at intel.com>
>>>
>>> Thanks for fixing this.
>>
>> Applied, thanks
>>
>> There are a lot of similar issues:
>>
>> git grep -l 'rte_errno = -E' | sed 's,[^/]*$,,' | sort -u
>>
>> drivers/event/opdl/
>> drivers/event/sw/
> <snip>
>> lib/librte_eventdev/
>
>
> I just checked the eventdev.h port_link() docs, which indicate negative return values.
> Perhaps the header is wrong too - but the PMDs adhere to the library header in this case.
>
> Is there a requirement for rte_errno to be positive?
> It looks to be declared as per-lcore signed int in rte_errno.h +20
>
> Either-way, if we want to change the PMDs, we should change the Eventdev APIs,
> which means API breakage, and application changes to handle changed return values.
>
> Sound like more work than it is worth it to me?
>
To be clear, documentation doesn't *explicitly* spell this out, so it
can be interpreted as not having an opinion on this. So i think the
first step should be fixing documentation to clearly indicate this is to
be expected at least of new code (unless decided against for consistency
reasons).
However, while docs don't state this outright, i think they imply it
both in cases of referring to errno values and returning "-errno" values
(which implies sign isn't part of the errno value). Plus, errno values
in Linux are always positive, plus rte_strerror() expects a positive
value, and (as correctly pointed out by Harry) our custom errno values -
so at least our API expects it to be positive, even if it doesn't state
it outright.
--
Thanks,
Anatoly
More information about the dev
mailing list