RE: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches (1/3)

It sounds good. :) 

And we could use the same system sys_set/get_thread_area(). :p

Here is the draft modication. Do I miss or misunderstand sth? If no,
I could update the kernel & glibc patch. thanks. 

glibc&nptl : 
struct pthread * __thread_self; 
#define THREAD_SELF (__thread_self)

arm-kernel: 

pd_addr:  __thread_self
pd_addr_addr: &__thread_self
It is the duty of kernel to update the content of pd_addr_addr. 

struct user_desc {
	void * pd_addr;
	void * pd_addr_addr;
}

struct thread_struct {
+	void * pd_addr;
+	void * pd_addr_addr;
}

sys_set/get_thread_area(struct user_desc *u_info)
{
     set/get the info(pd_addr & pd_addr_add) to current->thread; 
}

in kernel-source/include/asm-arm/system.h
 80 #define switch_to(prev,next,last)                                       	\
 81         do {                                                            		\
 82                 __switch_to(prev->thread_info,next->thread_info); \
 83                 mb();                                                   		 \
+                    if (NULL != current->thread.pd_addr_addr) 	 \
+                    	if (copy_to_user(current->thread.pd_addr_addr, \
+		    current->thread.pd_addr, sizeof(current->thread.pd_addr))) \
+				return -EFAULT;                     		\
 84         } while (0)


 
boris


> -----Original Message-----
> From: Philip Blundell [mailto:[email protected]]
> Sent: 2003?5?29? 22:15
> To: Hu, Boris
> Cc: Libc-Alpha (E-mail); NPTL list (E-mail)
> Subject: Re: [PATCH] Native POSIX Thread Library(NPTL) ARM 
> SupportingPatches (1/3)
> 
> 
> On Fri, 2003-05-23 at 09:23, Hu, Boris wrote:
> > However, TLS is absent in arm toolchain. So here is a 
> work-around way. 
> > In the linux kernel, a thread register is simulated by an 
> additional field(pd_addr) 
> > to thread_struct and two system 
> calls(sys_get/set_thread_area()).  __thread 
> > keyword is disabled in glibc and nptl. Moreover, some code 
> related TLS in nptl 
> > is protected by the glibc macro USE_TLS. 
> 
> Thanks for working on this.
> 
> I wonder what the performance impact is of having a system call in
> THREAD_SELF.  If it turns out to be too great, it may be possible to
> reduce the overhead by adding some more support to the kernel.  What
> I've been thinking of is a way for applications to supply a pointer to
> the kernel (via a new system call), and have it store the 
> current thread
> ID at that address during context switch.  That way, retrieving the
> thread descriptor would be just a regular memory access.  I think it'd
> only add a handful of cycles to the context switch path, and that's a
> comparatively heavyweight operation already so it would probably
> disappear in the noise.
> 
> p.
> 
>