Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Same issue exists in user space. And rt_cond_wait_inner needs fixing.
>>> And then there is a spurious sign inversion:
>>>
>>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c
>>> index 478321d..f874678 100644
>>> --- a/src/skins/native/cond.c
>>> +++ b/src/skins/native/cond.c
>>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout)
>>>  				&saved_lockcnt, XN_REALTIME, &timeout);
>>>  
>>>  	while (err == -EINTR)
>>> -		err = -XENOMAI_SKINCALL2(__native_muxid,
>>> -					 __native_cond_wait_epilogue, mutex,
>>> -					 saved_lockcnt);
>>> +		err = XENOMAI_SKINCALL2(__native_muxid,
>>> +					__native_cond_wait_epilogue, mutex,
>>> +					saved_lockcnt);
>>>  #endif /* !CONFIG_XENO_FASTSYNCH */
>> Ok for the sign inversion, but in this case the status is Ok. We call
>> cond_wait_epilogue only if prologue returned -EINTR, and update the
>> status, this is what we want.
>>
>> There is only one way out which will not break the ABI: do not call
>> cond_wait_epilogue in the kernel-space cond_wait_prologue.
>>
> 
> Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait an
> -EINTR on mutex lock, we lose the former, don't we?
> 
> If we can't find a workaround, I'm for breaking the ABI for this
> particular service - but let's search for an alternative first.
> 

The only way around ABI changes: save the return code of cond_wait
/somewhere/ across prologue and epilogue syscalls - but where???

Jan