On Fri, 30 Nov 2007, Brad Boyer wrote:
* There are no spare registers available to designate as the thread
register. Therefore, kernel magic is needed to obtain the thread
pointer from userspace. Kernel helpers are provided in a vDSO since
they will need unwind information associated; see details below.
Compiler-generated code will use an ABI-defined function
__m68k_read_tp with that function handling the details of calling
the vDSO.
Have you thought about where this pointer will be stored? A vDSO is
normally shared across all processes and has no thread specific data.
With it being abstracted out this way, it wouldn't need to be documented,
but I'm curious if you have any better ideas than just making it a
system call to read and write this value and store it in the thread
context structure.
With the ARM magic kernel page the pointer is stored at another location
in that page - we decided against using a magic page with a fixed address
as part of the interface on m68k/ColdFire, in favour of using a vDSO,
because of unwinding and debugging problems associated with executing code
in a magic page (whereas a vDSO acts more or less like another shared
library from that point of view), but the kernel could choose to map
another page per thread (at a fixed address but not one used directly
except by the vDSO and not one used for any executable code) and keep the
thread pointer in there. Or it could use a system call, though that would
be slower.
The helper __kernel_atomic_cmpxchg_32 compares the 32-bit value at the
location pointed to by a0 with the value in d0. If the values are
equal, it writes the value in d1 to the location pointed to by a0;
otherwise, it writes the value at the location pointed to by a0 to d0.
It does not clobber any registers other than the condition codes (and
the modification of d0 indicated so that d0 is returned with the
original value of the memory location in all cases). (On m68k - where
this kernel helper would only be used if glibc is built for the
intersection of ColdFire and m68k - this could be implemented with a
single cas instruction and a return.)
I presume ColdFire is also missing CAS2. Do we need a 64 bit cmpxchg
equivalent as well?
No, 32-bit compare-and-exchange suffices for NPTL; it's the only one for
which ARM has a kernel helper, and the others are set to cause NPTL to
fail to link if they get used. (If a future version of NPTL starts to
need more atomic operations, then we may need to add more kernel helpers
at that point.)
The helper __kernel_atomic_barrier provides a memory barrier. It does
not clobber any registers other than the condition codes. On non-SMP,
it can just return to the user; on SMP it needs to ensure memory
synchronization between processors.
Can you get SMP ColdFire boxes? Linux has historically not supported
SMP on m68k, and much of the code isn't really SMP safe (particularly
some of the drivers for 68k based systems). This isn't to say we
shouldn't have this option, but it seems like a low priority.
I don't know if SMP exists at present, but the aim is that glibc binaries
built now should work on any future SMP hardware and kernels, which seems
to require a kernel barrier operation unless you know there will never be
SMP hardware (or that such hardware will have a memory architecture not
needing the barriers).
--
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
