Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I pushed the changes fixing the u_mode (taken from Jan, slightly
>> modified) and condvar stuff (not entirely taken from Jan's changes), as
>> well as the modifications coming from Philippe's branch.
>>
>> However, two questions remain open:
>> - as in Jan's original patch, the u_mode stuff tests the presence of the
>> new syscall by testing whether it returns -ENOSYS. Now that we have the
>> vdso, I wonder if we should not use a vdso bit for this. This would give
>> us a systematic way of testing such syscalls extension.
> 
> I would prefer this path over -ENOSYS testing as well. We could collect
> the bits once and just test for it in-place. No more setup needed then
> when adding more (for cond e.g.).
> 
>> - the condvar fix only fixes the general case, using errno, it does not
>> add any new syscall. I am not entirely convinced we really need to add
>> new syscalls. In fact we could use special values in the existing ones.
>> Or have access in kernel-space to the a process' vdso flags, allowing to
>> adapt according to these flags. I am simply wondering what is the
>> cleanest way.
> 
> I think the cleanest way are separate syscalls. The existing prologue
> syscalls of both skins are already at their limits (5 arguments), so
> adding something here is not easy.

That can be done:
the prologue syscall has a "timed" parameter to which the old versions
always passed O or 1, we only have to pass 2 or 3 to mean 0 and 1, only
with the newer user-space. As for the epilogue syscall, we can multiplex
the prologue return value (ten bits for instance is plenty) in the upper
bits of the count returned to user-space. A recursive lock count of 4
million is a reasonable limit anyway. I just wonder if these tricks are
worth the trouble.

 Of course, you could switch the
> behavior per process depending on negotiated caps. But will this be
> simpler? What of the dispatching work for separate syscalls could be
> avoided that way?
> 
> Jan
> 


-- 



                                            Gilles.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to