如果dtrace和mdb这些工具运行在OpenSolaris全局zone中，那么这些工具对运行在跑有Solaris 10的zone中的进程来说是无用的，主要是因为Solaris 10和OpenSolaris之间部分调试库的一些不兼容的改变，导致Solaris 10不能作为OpenSolaris的zone正常地运行。同时，由于新版本的OpenSolaris加入了Crossbow等许多非常优秀的特性，让运 行Solaris 10的zone能充分利用OpenSolaris作为全局zone的众多优势，也是非常有必要的。本文将介绍如何解决在OpenSolaris上正常运行 跑有Solaris 10的zone这个技术难题。
解决这个问题最大的难点之一，就是x86平台下Solaris 10的libc对%fs段寄存器的使用。Solaris 10的libc希望X86平台64位处理器的%fs寄存器来存储非0的selector值（如果%fs值为0，那么Solaris 10的_curthread()返回NULL），问题也由此产生了，由于OpenSolaris的内核清空了%fs，而在64位的x86机器上，libc 总是使用%fs来查找当前线程的ulwp_t数据结构，从而使运行Solaris 10的zone不能使用libdoor这些普通的类库和thr_main(3C)等关键libc函数。
整个解决方案比较复杂，因为必须保证在Solaris 10 zone中运行的所有线程开始运行时%fs寄存器的值非零。幸运的是，在Solaris 10和OpenSolaris中只有两个系统调用修改了%fs：SYS_lwp_private和SYS_lwp_create。 SYS_lwp_private是一个libc私有的系统调用，只有在一个进程执行后libc初始化时才被调用一次，用来配置FS段使其段基址在单一线程 ulwp_t结构的开始处。
具体过程如下：
1. Solaris 10的仿真库在s10_lwp_private()实现SYS_lwp_private，它把系统调用传到未改变的OpenSolaris内核，然后调用 thr_main(3C)来测试Solaris10环境下的libc在内核配置%fs后是否运行正常。如果返回-1，那么将调用一个特殊的 SYS_brand系统调用将%fs还原到过去的非零状态。
2. Solaris 10的仿真库在s10_lwp_create()中实现SYS_lwp_create，使得新的线程在 s10_lwp_create_entry_point()而不是在_thrp_setup()中启动。当然，新的线程最终还是必须执行 _thrp_setup()，所以s10_lwp_create()在新线程栈中的预定位置保存_thrp_setup()的地址。 s10_lwp_create_entry_point()调用thr_main(3C)测试当%fs为零时Solaris 10的libc运行是否正常。如果thr_main(3C)返回-1，那么新的线程将调用和s10_lwp_private()一样的SYS_brand 系统调用来恢复%fs。然后，新的线程再从栈中的预定位置读取真正的入口点地址并跳转到入口点。
3. 在运行Solaris 10的zone里保证fork产生的子线程继承其父线程的%fs selector值，从而使父线程即使在调整%fs寄存器后也能保持父子线程的一致性。
4. 同时，还需要考虑对SIGCANCEL等信号的处理，以防止段错误的出现。