Re: cobalt-like pthread wrappers for evl

Thanks all,
today I implemented the functions I needed immediately (not many at all: mostly pthread_mutex and pthread_cond stuff, then pthread_create and) as a shared library and it seems to work so far. I reused pieces of xenomai-3 (macros and the wrappers.c file) and I have some very inelegant statically allocated maps to map user-supplied "pthread" pointers to evl objects. Note that nothing pthread is actually called for mutex and conds: the user-provided pointers are simply used as keys in the maps. Also, this assumes that evl_init() is called somewhere else before the application starts calling into these functions.

Here it is for those interested: https://github.com/giuliomoro/wrappers

It seems to be mostly working for me, but it's half day's work with half hour testing, so it comes without any warranties. Looking forward to the proper upstream solution.

Best,
Giulio

Philippe Gerum wrote on 13/02/2026 09:15:
> Florian Bezdeka <[email protected]> writes:
> 
>> Hi Giulio,
>>
>> [ Cc + Philippe ]
>>
>> On Thu, 2026-02-12 at 22:33 -0500, Giulio Moro wrote:
>>> Hi there,
>>> I have to port a large-ish C application to EVL. The application uses pthread_mutex, pthread_cond etc. Porting it to Xenomai-3 was straightforward, thanks to libcobalt and linker wrapping.
>>>
>>> Is there anything similar to that currently available for EVL? Maybe someone's half-tested branch stashed somewhere? Much appreciate any pointers that will save me from starting from scratch.
>>
>> That topic is most likely stuck in the design phase. Maybe Philippe can
>> comment on the current state. The topic was discussed a few times in the
>> past but never got traction.
>>
>> Maybe it's time to revive this topic.
>>
> 
> POSIX support for evl is indeed brewing in the design phase, which -
> good news - is about to be complete. This is not going to be a wrapper
> over libevl services, but a full-fledged interface - involving a
> dedicated kernel driver calling into the evl core - because we want the
> resulting API to comply with the standard.
> 
> e.g. the standard states that timeout specs passed to some POSIX
> services may not be accessed until such service actually wants to block
> the caller. libevl is at odds with this behavior, since it
> unconditionally accesses the timespec struct on entry to the call. The
> same way, the evl core immediately accesses the uniform timespec
> prepared by libevl. Also, libevl shares objects between processes by
> opening /dev/evl/* devices, while POSIX relies on shared memory for the
> most part. Those kind of things.
> 
> So, yes there is going to be a POSIX interface for evl, and this is on
> top of my (xenomai) todo list to work on it. However, this won't be
> done overnight as you can imagine.
> 
> PS: there used to be the opposite wrapper at some point in libevl
> called the evl-shim, implementing the evl API over POSIX.
>