Hi Ramin,

On Thu, 15 Oct 2026, Ramin Moussavi wrote:

> On Sun, Sep 27, 2026 at 02:58 AM Imre Kaloz wrote:
>> so a C library can use one casa for its 32-bit atomics on any V8 part.
>
> I sent a series covering part of the same ground, Magnus and Adrian
> pointed me here -- I had not seen yours, so we worked on the same
> problem in parallel:
> https://lore.kernel.org/sparclinux/20261015085545.3246951-1-ramin.moussavi@yacoub.de/
>
> Your casa emulation looks like a good approach to me. What I would
> still need is a way for a C library to find out whether the kernel
> has it: a library built for v8 needs to keep its own fallback for
> older kernels, and there casa is SIGILL. I see three ways a library
> could tell:
>
> - an AT_HWCAP bit, like HWCAP_SPARC_CASTRAP in Magnus' RFC but meaning
>  "casa works, in hardware or emulated",
> - a system call it can probe for ENOSYS, like patch 4 of my series,
> - or trying casa once under a SIGILL handler at startup.
>
> I know glibc does not want arch-specific atomics: on v8 the compiler
> turns the atomic builtins into calls, and glibc would rather have
> libgcc implement those with casa. But libgcc then faces the same
> question, unless it simply requires a kernel with the emulation; and
> uClibc-ng in my case keeps a fallback for older kernels. So from the
> kernel side the question how a library can tell remains.

Thanks, glad the approach works for you too.

My own view is that moving a C library to casa means rebuilding it
anyway, and that build can simply require a kernel with the
emulation, as with any other new kernel feature a library starts to
depend on. On an older kernel it stops with SIGILL at the first
casa, which at least fails clearly. A library that wants to keep its
fallback can probe casa once under a SIGILL handler, and that works
on every kernel without new ABI. Whichever way you go, use ASI 0x0A:
it also runs natively on LEON parts that have casa.

Whether the kernel should offer an explicit way to tell is Andreas˘
call, though. Andreas, if you˘d like one, I˘m happy to add whatever
you prefer, an AT_HWCAP bit or something else.


Thanks,
Imre