From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 18:49:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C65D316A4CE for ; Fri, 8 Apr 2005 18:49:56 +0000 (GMT) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF6E943D2F for ; Fri, 8 Apr 2005 18:49:53 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j38Imf5I029395 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 9 Apr 2005 04:48:43 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j38Ime7l094151; Sat, 9 Apr 2005 04:48:40 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j38Imdao094150; Sat, 9 Apr 2005 04:48:39 +1000 (EST) (envelope-from pjeremy) Date: Sat, 9 Apr 2005 04:48:39 +1000 From: Peter Jeremy To: "M. Warner Losh" Message-ID: <20050408184838.GC89047@cirb503493.alcatel.com.au> References: <200504061737.18204.michaelnottebrock@gmx.net> <20050407.211210.100582852.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050407.211210.100582852.imp@bsdimp.com> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: machdep.conspeed sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2005 18:49:56 -0000 On Thu, 2005-Apr-07 21:12:10 -0600, M. Warner Losh wrote: >In message: <200504061737.18204.michaelnottebrock@gmx.net> > Michael Nottebrock writes: >: However, a loader-tunable comconsole speed would *really* be useful IMHO, so >: perhaps someone could try and make it happen for real? :-) > >I backed it out because there was some problem that bde pointed out to >me. I can no longer recall what that was... The log says: "Until I can figure out how to live without the volatile qualifier on comdefaultrate, comment out the support for machdep.conspeed for now." Presumably gcc and/or bde complained that TUNABLE_INT() expected an "int *" but was passed "volatile int *". bde made it volatile in 1.162 though it's not clear to me why the volatile is needed here. I probably need to go and have a close study of exactly what a compiler is permitted to optimise away in the absence of 'volatile'. Rather than try and remove the 'volatile', an alternative approach would be to expand TUNABLE_INT() and use a an alternative to tunable_int_init() that could handle the volatile: Replace the current line with (untested): void tunable_comdefaultrate_init(void *data __unused) { int rate; TUNABLE_INT_FETCH("machdep.conspeed", &rate); comdefaultrate = rate; } SYSINIT(Tunable_init_comdefaultrate, SI_SUB_TUNABLES, SI_ORDER_MIDDLE, \ tunable_comdefaultrate_init, NULL) -- Peter Jeremy