On Tue, 26 Jun 2012 12:29:49 +0000 (UTC), Thorsten Glaser <t...@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 -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20457.53942.451105.716...@pilspetsen.it.uu.se
