core: use standard c atomic code from stdatomic.h instead of providing assembly routines

[linuxmaniac]

From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886111

Source: kamailio
Version: 5.1.0-1
Severity: wishlist

Hi,

I noticed from the build log on mips64el a lot of warnings like this:
> In file included from ../../core/parser/../mem/../atomic/atomic_native.h:50:0,
>                  from ../../core/parser/../mem/../futexlock.h:42,
>                  from ../../core/parser/../mem/../lock_ops.h:75,
>                  from ../../core/parser/../mem/shm.h:39,
>                  from ../../core/parser/../mem/shm_mem.h:34,
>                  from ../../core/parser/../ut.h:45,
>                  from ../../core/parser/../ip_addr.h:39,
>                  from ../../core/parser/msg_parser.h:37,
>                  from app_sqlang_api.h:28,
>                  from app_sqlang_kemi_export.c:32:
> ../../core/parser/../mem/../atomic/atomic_mips2.h:41:2: warning: #warning mips64 atomic code was not tested, please report problems to serdev@iptel.org or andrei@iptel.org [-Wcpp]
>  #warning mips64 atomic code was not tested, please report problems to \
>   ^~~~~~~

If possible, kamailio should use the standard c atomic code from
stdatomic.h instead of providing assembly routines. This will improve
maintainability and architecture support.

Thanks,
James

[miconda]

I agree we should move to a standard libc approach when possible, I wanted to look at this for quite some time, but not much happened. For now, I am not sure if it is a good compatibility between operations to just say it will be done.

On the other hand, I think that these compile time warnings are useless in most of the cases, because more and more people install from packages, so they do not build the app. They should be turned into some startup warnings, so people have a chance to see them when running kamailio..

[henningw]

In commit 65fab0d at least the old e-mail address has been changed.
The main obstacle to change to the standard MIPS atomic instructions are probably our limited test options for this architecture.

[github-actions]

This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.