On Fri, Nov 30, 2007 at 07:05:05PM +0000, Joseph S. Myers wrote:
CodeSourcery has been investigating implementing TLS (Thread-Local Storage) and NPTL (Native POSIX Thread Library) for ColdFire processors. The proposed TLS ABI for ColdFire and m68k, including the required kernel interfaces, is below; any comments?
It's good to see someone with more incentive working on this. I had started looking at it, but it was never exactly a high priority. If it makes sense for you, I'd like to help out with this. However, I know many of the steps required have to be pretty serialized. This would make coordination with someone outside your internal scheduling somewhat more complicated, I imagine. Let me know if there's something that would really help you out, otherwise I'll just continue poking at it on my own once in a while.
* 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.
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?
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. Brad Boyer flar@xxxxxxxxxxxxx - 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
