From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 23:08:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CDFF16A4DD for ; Mon, 28 Feb 2005 23:08:15 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D97843D4C for ; Mon, 28 Feb 2005 23:08:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7957 invoked from network); 28 Feb 2005 23:08:14 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 28 Feb 2005 23:08:14 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1SN84OC066576; Mon, 28 Feb 2005 18:08:08 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 28 Feb 2005 17:23:33 -0500 User-Agent: KMail/1.6.2 References: <421E7867.9060101@samsco.org> <20050225093917.GA90508@cirb503493.alcatel.com.au> In-Reply-To: <20050225093917.GA90508@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502281723.33667.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Peter Jeremy cc: Scott Long cc: hackers@FreeBSD.org Subject: Re: Driver Update Disk discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 23:08:15 -0000 On Friday 25 February 2005 04:39 am, Peter Jeremy wrote: > On Thu, 2005-Feb-24 17:59:19 -0700, Scott Long wrote: > >- kernel option support. How do we support vendor modules in a kernel > >that might be compiled with PAE (rather common these days), SMP, MAC, > >etc. The loader and /boot infrastructure has no concept of this. It's > >highly important, though. > > AFAIK, PAE is only relevant on iA32. I second the suggestion that PAE > be treated as a distinct architecture for these purposes. > > INVARIANTS and WITNESS are the other options that impact ABI. These > are probably unnecessary on -RELEASE but it would be nice if people > could build a kernel with WITNESS and not have it panic if they loaded > a module that wasn't compiled with WITNESS (which I think it the > current behaviour). No, WITNESS is completely opaque to modules. If a module uses a spin lock, there is extra trickiness involved, but that should really be a rare case. INVARIANTS modules work fine if INVARIANT_SUPPORT is in the kernel. INVARIANT_SUPPORT usually means that functions like _mtx_assert() are present in the kernel. Perhaps INVARIANT_SUPPORT should simply be on by default. MUTEX_PROFILING is one option that changes the ABI, but that is purposeful as that's really a development tool. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org