From owner-freebsd-stable@FreeBSD.ORG Mon Dec 6 15:50:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7713106564A for ; Mon, 6 Dec 2010 15:50:22 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1CF8FC12 for ; Mon, 6 Dec 2010 15:50:21 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA11762; Mon, 06 Dec 2010 17:50:12 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD0633.9060509@freebsd.org> Date: Mon, 06 Dec 2010 17:50:11 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> In-Reply-To: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Could MSGBUF_SIZE be made a loader tunable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 15:50:23 -0000 on 06/12/2010 07:20 perryh@pluto.rain.com said the following: > Would there be some fundamental problem in changing MSGBUF_SIZE > from a compiled-in constant to a tunable that could be set at the > loader prompt? (I'm _not_ suggesting that it be adjustable while > the system is running.) > > The upside would be that, if someone needed a larger buffer > temporarily to accommodate trace data from a mechanism such as > kern.geom.debugflags, the size could be adjusted without having > to rebuild the kernel. > > I didn't see any obvious downside from examining the 8.1-RELEASE > code, but I could certainly have overlooked some subtle (or even > blatant) reason why this would be a Bad Idea. I also don't immediately see why that wouldn't work. Can you try to come up with a patch? -- Andriy Gapon