From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 00:59:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0BFBFFE for ; Wed, 19 Nov 2014 00:59:18 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C0FDDE0E for ; Wed, 19 Nov 2014 00:59:18 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 814252291F; Tue, 18 Nov 2014 16:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1416358758; x=1416373158; bh=7qjDjZNSlrIQT1W/y7iWhDw+UMw+5Bl6V81cSuQbv98=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=IvYrJCdBJTjdubjg8bnaBtdZNT73IM6JsqCun9AoIx7oz5w5uWsR3XNOROUWThouC E51IEIAY69mSHp36uFHfHLUuAhWQH40MyPXFcTHXOtfx39M0Z5AC8h7/sfZbQCPegX 65y3emH2yGdLL+CG7Er+aWnF/NvkuDkNcinp/WAA= Message-ID: <546BEB66.6050909@delphij.net> Date: Tue, 18 Nov 2014 16:59:18 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Slawa Olhovchenkov , d@delphij.net, "freebsd-arch@FreeBSD.org Arch" Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> In-Reply-To: <20141119003632.GN24601@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 00:59:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/18/14 16:36, 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... Actually the loader can unload everything ("unload"), and after that you would have to load them back individually. The challenge is that having the same code in multiple modules would incur more I/Os (because the need to visit more file system structures, etc.) and possibly slightly more memory. In loader stage, I/Os would be slow and doing so would slow down boot. A way to mitigate this is to compress the modules, but that would break a few applications like DTrace which needs to be taught to read compressed modules. It would be, however, a win if we could strip down the kernel significantly and only load the _required_ modules that are sufficient to support the kernel to start /etc/rc, where we can load additional modules on demand (via devd for instance) because this would reduce I/O at loader stage. I think we need to teach loader to determine which storage drivers and possibly NFS and network devices to load. On FreeNAS we have moved many of non-essential modules to after boot stage but please please consider opening a new thread on this topic as they have nothing to do with our kernel linker module version support... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUa+tmAAoJEJW2GBstM+ns470P/RFgzwEpQABzheEW/NmZ1I+y jPPhKYmbG8pgEhr6S0JeuROLfoocFVI9JkO+4R5M8prEnHUWyfyNyz9oYJ8om3rk 31zmnHRX7nb5szlSRsbXHNNrqFIlNnTWLaCpNn6r7PINYdoUfj8IOv7buDOTFgPf WNQzG2yAsMztbOjmOk7U87BwvN97Ko+k+lLuqfsODnjqiBngrR95utTnnAdyQoOf azydh6gcdXars0ci0xPTKEnm7CcuRK/xU1LNGUUD3CUYVFpQ1o4noXBDJsSzVcbk g/SSrL2voIf6VF+8RKc4Q3CG5e2v35DpPoOP/Jf4kAkhtab3Nyu4pYtDAnsoTVFq JL3wt7Uik/RUw+dDOBhGWtM3rzwPNL2zEGkYP5QtIb2Xe+KkTCWQJHyq1+XhavmI cbvYywzBXHI/JF7Y4LyVkV8q8ZPrBfSlBmOtjdC1IA5P7rmSIZzoso2/uwv2w2Rj 4vZ7o5MExR0sZdV8klWzbenMGhx/wdzjAxZ4rD5fE3bvCGNaXQ+gzVDHCbzyD4pq kS0oAZVSDfv2zrKMowvEkPHrUmjuJ1IsFLi51raSTDSKLwfjVKjI5qVwxi3isPMb ZZRk/bu6XsJ+sd0ODhy3kTXiFK+NfUwMeryngRUuh5yBVF1xkYnZ/7z7bLzIIgzI mZvxLgylFYdwnEu0kiHd =xhPp -----END PGP SIGNATURE-----