[xenomai4] POSIX API

[xenomai4] POSIX API

[Philippe Gerum]

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.

Re: [xenomai4] POSIX API

[Giulio Moro]

Thanks for sharing this with the list.

>>> __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.

I am not sure I have a full grasp of the suggested approach, but I'll share a request for clarification/feature. On Xenomai 3 it is currently possible to avoid link-time wrapping and explicitly calling the `__wrap_func()` version, while regular `func()` calls result in the stock version (equivalent to `__real_func()`). I find this behaviour useful and would like it to be preserved in Xenomai 4. I hope this will still be possible for at least some combination of build flags.

Best,
Giulio

Re: [xenomai4] POSIX API

[Philippe Gerum]

Giulio Moro <giulio@bela.io> writes:

> Thanks for sharing this with the list.
>
>>>> __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.
>
> I am not sure I have a full grasp of the suggested approach, but I'll
> share a request for clarification/feature. On Xenomai 3 it is
> currently possible to avoid link-time wrapping and explicitly calling
> the `__wrap_func()` version, while regular `func()` calls result in
> the stock version (equivalent to `__real_func()`). I find this
> behaviour useful and would like it to be preserved in Xenomai 4. I
> hope this will still be possible for at least some combination of
> build flags.
>

Yes, this will be preserved for x4. The approach I'd like to see should
prefer explicit over implicit when it comes to wrapping, the use case
you described falls into this category.

-- 
Philippe.