On 16/10/2023 20:11, Jason Gunthorpe wrote:
> On Sat, Oct 07, 2023 at 03:40:50AM +, Zhijian Li (Fujitsu) wrote:
>> +rdma-core
>>
>>
>> Is global variable *errno* reliable when the documentation only states
>> "returns 0 on success, or the value of errno on failure (which indicates the
>> fai
On Sat, Oct 07, 2023 at 03:40:50AM +, Zhijian Li (Fujitsu) wrote:
> +rdma-core
>
>
> Is global variable *errno* reliable when the documentation only states
> "returns 0 on success, or the value of errno on failure (which indicates the
> failure reason)."
I think the intention of this langua
+rdma-core
Is global variable *errno* reliable when the documentation only states
"returns 0 on success, or the value of errno on failure (which indicates the
failure reason)."
Someone read it as "assign error code to errno and return it.", I used to think
the same way.
but ibv_post_send() doe
Let me try to map solutions.
Markus Armbruster writes:
> migration/rdma.c uses errno directly or via perror() after the following
> functions:
>
> * poll()
>
> POSIX specifies errno is set on error. Good.
Nothing wrong, nothing to do.
> * rdma_get_cm_event(), rdma_connect(), rdma_get_cm_eve
migration/rdma.c uses errno directly or via perror() after the following
functions:
* poll()
POSIX specifies errno is set on error. Good.
* rdma_get_cm_event(), rdma_connect(), rdma_get_cm_event()
Manual page promises "if an error occurs, errno will be set". Good.
* ibv_open_device()
"Zhijian Li (Fujitsu)" writes:
> On 26/09/2023 13:50, Li Zhijian wrote:
>>
>>
>> On 18/09/2023 22:41, Markus Armbruster wrote:
>>> Functions that use an Error **errp parameter to return errors should
>>> not also report them to the user, because reporting is the caller's
>>> job. When the call
"Zhijian Li (Fujitsu)" writes:
> On 18/09/2023 22:41, Markus Armbruster wrote:
>> Functions that use an Error **errp parameter to return errors should
>> not also report them to the user, because reporting is the caller's
>> job. When the caller does, the error is reported twice. When it
>> doe
On 26/09/2023 13:50, Li Zhijian wrote:
>
>
> On 18/09/2023 22:41, Markus Armbruster wrote:
>> Functions that use an Error **errp parameter to return errors should
>> not also report them to the user, because reporting is the caller's
>> job. When the caller does, the error is reported twice.
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the e
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the e
Functions that use an Error **errp parameter to return errors should
not also report them to the user, because reporting is the caller's
job. When the caller does, the error is reported twice. When it
doesn't (because it recovered from the error), there is no error to
report, i.e. the report is b
11 matches
Mail list logo
