On Sat, Dec 01, 2007 at 01:08:07AM +0000, Joseph S. Myers wrote:
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.
I suppose we could add a page at a fixed virtual offset from the vDSO
base address. That would make the code sequence easier since we would
presumably could use PC-relative addressing in the vDSO code. This would
be much better than having a fixed virtual address. I'm just worried
about the overhead of having an extra page per thread to store 32 bits.
Any ideas on other things that could be put here to make it more worth
the cost? Perhaps there are some system calls we could turn into a
normal memory load out of this special page pre-loaded with data. The
powerpc port does a few system calls that way out of the vDSO, but it's
not anything thread specific since their data page is shared.
I also tried to look for the ARM magic page implementation, but I
couldn't find it. Any pointers to where I should be looking? I've
never done any work on ARM other than looking at some of the chip
documentation and some decidedly non-Linux implementations.
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
