From owner-cvs-all@FreeBSD.ORG Thu Dec 30 00:51:40 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FAEB16A4CE; Thu, 30 Dec 2004 00:51:40 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C1E43D46; Thu, 30 Dec 2004 00:51:39 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iBU0paGV004683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Dec 2004 16:51:37 -0800 Message-ID: <41D35117.4010505@root.org> Date: Wed, 29 Dec 2004 16:51:35 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Roberson References: <200412260013.iBQ0DcJ1074546@repoman.freebsd.org> <20041229020531.GA12575@dragon.nuxi.com> <41D26CE3.4070404@root.org> <20041229124826.Q60504@mail.chesapeake.net> <41D30245.8020600@root.org> <20041229151758.S60504@mail.chesapeake.net> <41D33C50.6090109@root.org> <20041229193531.M60504@mail.chesapeake.net> In-Reply-To: <20041229193531.M60504@mail.chesapeake.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys ktr.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 00:51:40 -0000 Jeff Roberson wrote: > On Wed, 29 Dec 2004, Nate Lawson wrote: >>>>Isn't there a way to dynamically allocate ids, like sysctl does for oid? >>> >>>They need to be static at compile time or they always produce massive >>>bloat in the kernel. >> >>Right, I thought we did something like that for other subsystems. I'm >>very fuzzy on the current best approach but in the past we used linker >>sets to gather a class of data at link time (including mod load). If >>the linker set was an id placeholder for a particular type of debug >>data, the kernel could overwrite this with the actual runtime id. > > > We already have a runtime mechanism for disabling a particular class that > could tolerate dynamic class ids. That's KTR_MASK. The issue I'm talking > about, is the ability to compile it out. Since gcc's dead code eliminator > doesn't run after link time, all ktrs would forever be compiled into the > kernel. Ok. It might be possible to mark such code with __init and KTR ids with __initdata. Then the linker can discard them if not using KTR. This is the approach Linux takes to reclaim memory from code/data that only needs to be accessed once, at boot. -- Nate