From: Jeff D. <jd...@ad...> - 2004-01-20 17:00:34
|
mi...@el... said: > unfortunately, this is only the case if the kernel is below 2.5.69 and > has 'nptl' in the uname. Otherwise ld.so assumes full NPTL support. So, it uses uname to figure out if the kernel has NPTL support? > so the only compatible solution seems to be to implement set/ > get_thread_area() within UML. Since UML itself is linked statically, > which causes the non-TLS glibc to be linked, i think it should be safe > to just shadow the TLS descriptors in the UML process and call > set_thread_area() for every new thread that has TLS descriptors not > equal to the previous thread's TLS descriptors. In tt mode, this is true. A skas-only UML will be dynamic, but then userspace is in a separate process, and someone was thoughtful enough to add PTRACE_[GS]ET_THREAD_INFO. So, this will be fine in either case. The problem is on 2.4. I suspect that this can't be emulated on 2.4 hosts, so a 2.6 UML can't boot a NPTL system on a 2.4 host. This is annoying since host version independence is a nice thing about UML. > but wrt. LinuxThreads - it doesnt seem UML skas mode implements LDT > state properly - does it? As far as I know, it does. LinuxThreads was introduced in RH8 or so, I think, and RH8 filesystems have run in UML for a long time. Jeff |