From owner-cvs-src@FreeBSD.ORG Mon May 17 14:59:50 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 786E716A4CE; Mon, 17 May 2004 14:59:50 -0700 (PDT) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40ACA43D4C; Mon, 17 May 2004 14:59:49 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i4HLx184005001; Mon, 17 May 2004 22:59:01 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer Date: Mon, 17 May 2004 22:59:00 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405172259.00791.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Peter Wemm Subject: Re: cvs commit: src/sys/kern kern_linker.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 21:59:50 -0000 I've been thinking about that on and off for a while. It would be fairly easy to represent most of struct pcpu using TLS... On Monday 17 May 2004 22:31, Julian Elischer wrote: > which brings up the question of TLS in the kernel :-) > > On Mon, 17 May 2004, Peter Wemm wrote: > > peter 2004/05/17 14:24:40 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/kern kern_linker.c > > Log: > > Since we go to the trouble of compiling the kobj ops table for > > each class, and cannot handle it going away, add an explicit > > reference to the kobj class inside each linker class. Without > > this, a class with no modules loaded will sit with an idle refcount > > of 0. Loading and unloading a module with it causes a 0->1->0 > > transition which frees the ops table and causes subsequent loads > > using that class to explode. Normally, the "kernel" module will > > remain forever loaded and prevent this happening, but if you have > > more than one linker class active, only one owns the "kernel". > > > > This finishes making modules work for kldload(8) on amd64. > > > > Revision Changes Path > > 1.111 +1 -0 src/sys/kern/kern_linker.c