From owner-freebsd-stable@FreeBSD.ORG Wed Dec 8 09:11:20 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 62A58106566C; Wed, 8 Dec 2010 09:11:20 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDBD8FC08; Wed, 8 Dec 2010 09:11:20 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id oB89BIPw096678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Dec 2010 01:11:18 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id oB89BI7Z096677; Wed, 8 Dec 2010 01:11:18 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01111; Wed, 8 Dec 10 01:09:47 PST Date: Wed, 08 Dec 2010 01:09:38 -0800 From: perryh@pluto.rain.com To: avg@freebsd.org Message-Id: <4cff4b52.WgKWgVaxljcckd8Z%perryh@pluto.rain.com> References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> <4CFD0633.9060509@freebsd.org> In-Reply-To: <4CFD0633.9060509@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 08 Dec 2010 09:11:20 -0000 Andriy Gapon wrote: > 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.) ... > > 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? I was planning to try it, unless someone pointed out a reason not to bother -- and then there is the same problem everyone else has, ENOTIME :( Sort-of related question, since the only 8.x I currently have is the not-yet-installed memstick: should I be able to build a usable 8.1 kernel on a 6.1 system (with the 8.1 sources installed somewhere, of course)?