[xenomai4] POSIX API

[Philippe Gerum <rpm@xenomai.org>]

Florian Bezdeka <florian.bezdeka@siemens.com> writes:

CCing the list. This is a combined discussion about bringing a POSIX API
to xenomai4 and getting rid of the --wrap linker trick for xenomai3 in
the same move.

> On Sun, 2024-11-17 at 18:52 +0100, Philippe Gerum wrote:
>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>> 
>> > I finally managed it to "publish" a branch [1] that holds my tries to
>> > get rid of the function wrapping in Xenomai 3.
>> > 
>> > smokey is already running fine, some TODOs are left. See commit
>> > messages for details.
>> > 
>> > Further tests with valgrind and the gcc sanitizer will hopefully follow
>> > soon. Seems I have to do some prctl()/syscall() refactorings first.
>> > 
>> > I would like to close the gap between Xenomai 3 and 4 as good as
>> > possible so that customers can easily move forward without touching
>> > code - ideally.
>> > 
>> > Best regards,
>> > Florian
>> > 
>> > [1] https://gitlab.com/Xenomai/xenomai-hacker-space/-/commits/flo/refactor-wrapping?ref_type=heads
>> 
>> Ok, I had a look at this code. I think I understood the key aspects of
>> it. I believe we can do without the trampoline which would make it CPU
>> independent. At least, I managed to implement the same scheme without
>> it [1], which eventually provides the very same support than we got with the
>> linker trick, i.e. for any frob() service from the POSIX API, we would
>> have:
>
> Yes, maybe I can remove the trampoline as well. Will try...
>
>> 
>> - __real_frob() /* original from glibc */
>> - __wrap_grob() /* a Xenomai implementation in libcobalt/libevl */
>> - __local_frob() /* a local (user-provided) override of __wrap_frob()
>> 
>> __real_frob() would require explicit call via some macro trick like
>> __STD() with libcobalt. Others would be invoked under the hood via a
>> plain call to frob(), depending on the insertion of liboverride.so
>> _before_ libposix.so on the linker command line.
>
> Yep. If we could get it flying this way it should be compatible to the
> Xenomai 3 world. __STD() for libc calls, nothing or __RT() for
> cobalt/evl calls.
>
>> 
>> I'm unsure the local override is that useful for the average user.
>
> Agree, for Xenomai 4 I would like to get rid of the user override.
> Unnecessary complexity - IMHO. 
>
> The situation is different for Xenomai 3. As I can't tell if someone is
> using that already - I heavily doubt that - I probably should keep the
> possibility to so. Backward compatibility...
>
>> 
>> Now, this hack would likely be an improvement over the --wrap directive
>> passed to ld, specifically because we'd not need wrap-link.sh to prevent
>> POSIX symbols in system libraries from being wrapped. As a matter of
>> fact, the technique illustrated in [1] relies on the library dependency
>> order on the link line to hide those symbols from the interposition we
>> would do. Only tested lightly, but this should work (see the Makefile).
>
> I did some tests in this direction as well. The results were promising,
> but more testing has to prove that.
>
>> 
>> BUT, this does not solve the fundamental issue I still see with these
>> more or less transparent interposition techniques which --wrap belongs
>> to as well: they all lack explicitness when it comes to clearly identify
>> who will handle the call by simply reading the source code. We still
>> need to understand the build context to figure out, which is a problem
>> because it's really error-prone, I believe. This is the aspect I'd like
>> to improve for libevl, if ever possible (maybe it is, I'm on something,
>> hopefully, but this requires more thought).
>
> Happy to hear your thoughts.
>
>> 
>> [1] git@source.denx.de:Xenomai/xenomai4/playground.git
>> 

-- 
Philippe.