Gilles Chanteperdrix wrote:
> 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. 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?
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Xenomai-core mailing list