Re: About gcc builtin atomics
On Tue, 26 Jun 2012 12:29:49 +0000 (UTC), Thorsten Glaser <tg@mirbsd.de> wrote:
> >OTOH, if CAS is provably unsafe in user-space for a sizeable portion
> >of the Linux/m68k HW base, then the kernel should IMO provide a
> >vsyscall page with at least CAS and DCAS/CAS64 entry points (doing
>
> And TLS!
>
> So who's going to be writing it? ;-)
I saw Andreas Schwab's comment last month about supporting get_thread_area
via a vdso <http://lists.debian.org/debian-68k/2012/05/msg00090.html>, but
given the m68k ISA I don't see any way of doing that except:
a) issuing a syscall, as is done today, or
b) having the kernel update a reserved location in a process' address
space whenever a thread in that process is resumed
The latter is what Linux/ARM does on pre-ARMv6 processors, but it entails:
- having a vsyscall page at a fixed location (vdso is too horrible), and
- updating a long word in it in each switch_to()
- SMP is initially prohibited, the get_thread_area entry needs to be a
proper function, so that a future SMP-capable system can be allowed,
either by reverting to doing a syscall, or by using an extended ISA
where the TLS pointer _can_ be retrieved directly in user-space
I could probably implement something like that, but I'm not sure how
the kernel maintainers would feel about a per-process vsyscall page...
/Mikael
Reply to: