Date: Tue, 18 Nov 2014 16:59:18 -0800 From: Xin Li <delphij@delphij.net> To: Slawa Olhovchenkov <slw@zxy.spb.ru>, d@delphij.net, "freebsd-arch@FreeBSD.org Arch" <freebsd-arch@freebsd.org> Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <546BEB66.6050909@delphij.net> In-Reply-To: <20141119003632.GN24601@funkthat.com> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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 <delphij@delphij.net> 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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?546BEB66.6050909>