From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Thu, 10 Jul 2008 21:25:13 +0200 From: cinap_lenrek@gmx.de In-Reply-To: <13426df10807100936l14a08d45n714428b086897d65@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-lttnstlvybpnzuytgbtpzwtoeh" Subject: Re: [9fans] why not Lvx for Plan 9? Topicbox-Message-UUID: e1bbfc7a-ead3-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-lttnstlvybpnzuytgbtpzwtoeh Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Ok, here is the thing... Here are 2 versions of linux libc tls and notls. (Current linux distries just ship with the tls version i think, but here may be exceptions) TLS is a libpthread thing that is heavily wired together with libc on linux. (just do an ldd on something like ls) TLS uses the two free segment registers %FS and %GS as a way for a thread to access its thread local storage area. (the parent allocates some memory and sets up an segment descriptor that points/translates to this memory (it makes set_thread_area() syscall todo this) to implement this syscall, i needed a way to change entries in the global descriptor table in the kernel. here is some experimental driver (/dev/tls) but i'm not sure if its correct. also it buys you not very mutch to have it yet, because the new pthread library also needs a futex implementation to be usefull. the old notls libc works without that syscall and doesnt need any modification to the plan9 kernel. but... i think in the near future TLS support is important and for that i need some kernel support to change segment descriptors on a process basis. If i understand vx correctly, it also needs a way to change segment descriptors and even needs to be able to change its %DS, %CS, %SS registers to it. cinap --upas-lttnstlvybpnzuytgbtpzwtoeh Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> X-Flags: 0000 Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 10 Jul 2008 16:43:16 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx076) with SMTP; 10 Jul 2008 18:43:16 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from <9fans-bounces@9fans.net>) id 1KGz89-0004jG-2G; Thu, 10 Jul 2008 16:36:29 +0000 Received: from fg-out-1718.google.com ([72.14.220.157]) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from ) id 1KGz83-0004j5-Nn for 9fans@9fans.net; Thu, 10 Jul 2008 16:36:24 +0000 Received: by fg-out-1718.google.com with SMTP id e21so1418758fga.28 for <9fans@9fans.net>; Thu, 10 Jul 2008 09:36:22 -0700 (PDT) Received: by 10.86.52.6 with SMTP id z6mr8881665fgz.18.1215707782263; Thu, 10 Jul 2008 09:36:22 -0700 (PDT) Received: by 10.86.57.20 with HTTP; Thu, 10 Jul 2008 09:36:22 -0700 (PDT) Message-ID: <13426df10807100936l14a08d45n714428b086897d65@mail.gmail.com> Date: Thu, 10 Jul 2008 09:36:22 -0700 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13426df10807100818g491f676fwf5f2256f710f0583@mail.gmail.com> Subject: Re: [9fans] why not Lvx for Plan 9? X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Htest: 0.71 X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: FwpDeXgCbUkpMMl0kWgnyvVkZ2hlN0ps On Thu, Jul 10, 2008 at 9:33 AM, Charles Forsyth wrote: >> speaking of which, did Cinap's fixes for the gs segment make it in so >> we have thread local storage a la linux now? > > > or did you mean in linuxemu? yes. linuxemu needed a kernel change IIRC and I was wondering if that was in. ron --upas-lttnstlvybpnzuytgbtpzwtoeh--