From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 09:00:47 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12BD1754; Wed, 19 Nov 2014 09:00:47 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC195641; Wed, 19 Nov 2014 09:00:46 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xr17z-000IXx-TP; Wed, 19 Nov 2014 13:00:43 +0400 Date: Wed, 19 Nov 2014 13:00:43 +0400 From: Slawa Olhovchenkov To: Ian Lepore Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141119090043.GB68953@zxy.spb.ru> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> <1416359781.1147.74.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416359781.1147.74.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: re , kyliel@microsoft.com, "weh@microsoft.com >> Wei Hu" , John-Mark Gurney , huishao@microsoft.com, "Jun Fang \(Wicresoft\)" , "freebsd-arch@FreeBSD.org Arch" , d@delphij.net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 09:00:47 -0000 On Tue, Nov 18, 2014 at 06:16:21PM -0700, Ian Lepore wrote: > On Tue, 2014-11-18 at 16:36 -0800, John-Mark Gurney wrote: > > Slawa Olhovchenkov wrote this message on Wed, Nov 19, 2014 at 04:27 +0400: > > > On Tue, Nov 18, 2014 at 04:15:10PM -0800, John-Mark Gurney wrote: > > > > > > > Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at 16:45 +0400: > > > > > On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > > > > > > > > > > > Right now one can declare version for a module by doing something like: > > > > > > > > > > > > MODULE_VERSION(module_name, module_version); > > > > > > > > > > > > Sometimes, it may be desirable for a vendor to release a new driver > > > > > > that overrides the driver shipped with the kernel itself. However, it > > > > > > seems that the MODULE_VERSION facility would just refuse the module > > > > > > when preloaded with kernel. > > > > > > > > > > > > Looking at some other vendor drivers, they are using a slightly > > > > > > different module name to overcome this limitation. Is that the only > > > > > > way to do it? > > > > > > > > > > I think now time to move to modulated kernel and load all drivers > > > > > currently present in GENERIC as modules (via loader.conf). > > > > > > > > This becomes slightly more difficult for storage drivers which must > > > > be loaded at boot time so the you can mount root from it... But yes, > > > > we are interested in methods to make it easier/more automatic for > > > > modules to be loaded to support the hardware that is present in a > > > > system... > > > > > > When loader can load kernel -- loader can load driver module, this is > > > not Linux (but yes, loader need plugable and stackable framework for > > > access FS -- currenly booting from ZFS over gstripe not allowed). > > > > That isn't the only issue.. another issue is identifing the correct > > kernel module(s) to load at boot... iirc, you cannot unload a kernel > > module loaded at boot time... > > > > You can do a kldunload on a module that was loaded by loader(8) and it > will be unlinked from the kernel in terms of symbol resolution, but the > memory cannot be freed. You can then load and unload the same module > again as much as you want, it just won't re-occupy the original address, > and the original memory is lost forever (but considering the size of > most modules, that's not such a big deal). Some modules can't be unloaded anyway: netgraph, for example.