Discussion:
modules finding order
Baptiste Daroussin
2017-04-16 20:21:37 UTC
Permalink
Hi all,

I would like to change in FreeBSD 12 at least the default order the modules are
found/look up.

For now the modules are loaded from /boot/kernel first then if not found,
checked from /boot/modules.

I think we should revert that to /boot/modules first then /boot/kernel.

The main reason being to simplify multiple things:
1/ If one needs to change a module (like backporting) I could install it from
package and it would take precedent from the one provided by the default kernel
I'm using
2/ As a hacker I could build my own version of a given module and install it in
/boot/modules I won't overwrite the default kernel module
3/ as a port maintainer I could provide my own version of the module that would
take precedence over the one provided by the kernel.

As it is a change in the default behaviour I would only do it for 12 (beside I
would love to do it in earlier version :D)

Anyone has an opinion on the subject?

Best regards,
Bapt
Mark Johnston
2017-04-16 22:12:49 UTC
Permalink
Post by Baptiste Daroussin
Hi all,
I would like to change in FreeBSD 12 at least the default order the modules are
found/look up.
For now the modules are loaded from /boot/kernel first then if not found,
checked from /boot/modules.
I think we should revert that to /boot/modules first then /boot/kernel.
1/ If one needs to change a module (like backporting) I could install it from
package and it would take precedent from the one provided by the default kernel
I'm using
2/ As a hacker I could build my own version of a given module and install it in
/boot/modules I won't overwrite the default kernel module
This complements r299393. Since that revision went in I've confused myself
several times by building and installing a module from sys/modules, and
then forgetting to explicitly kldload from /boot/modules, so I
instead get a stale copy.
Post by Baptiste Daroussin
3/ as a port maintainer I could provide my own version of the module that would
take precedence over the one provided by the kernel.
I think we would like this behaviour for a port that installs the DRM
modules.
Post by Baptiste Daroussin
As it is a change in the default behaviour I would only do it for 12 (beside I
would love to do it in earlier version :D)
Anyone has an opinion on the subject?
It seems reasonable to me.
Gary Jennejohn
2017-04-17 06:58:22 UTC
Permalink
On Sun, 16 Apr 2017 15:12:49 -0700
Post by Mark Johnston
Post by Baptiste Daroussin
Hi all,
I would like to change in FreeBSD 12 at least the default order the modules are
found/look up.
For now the modules are loaded from /boot/kernel first then if not found,
checked from /boot/modules.
I think we should revert that to /boot/modules first then /boot/kernel.
1/ If one needs to change a module (like backporting) I could install it from
package and it would take precedent from the one provided by the default kernel
I'm using
2/ As a hacker I could build my own version of a given module and install it in
/boot/modules I won't overwrite the default kernel module
This complements r299393. Since that revision went in I've confused myself
several times by building and installing a module from sys/modules, and
then forgetting to explicitly kldload from /boot/modules, so I
instead get a stale copy.
Post by Baptiste Daroussin
3/ as a port maintainer I could provide my own version of the module that would
take precedence over the one provided by the kernel.
I think we would like this behaviour for a port that installs the DRM
modules.
Post by Baptiste Daroussin
As it is a change in the default behaviour I would only do it for 12 (beside I
would love to do it in earlier version :D)
Anyone has an opinion on the subject?
It seems reasonable to me.
The problem I see with this is that the module under
/boot/modules may have been generated against a /usr/src which is
newer than what was used to generate the running kernel. In this
case kldload should (I hope) fail.

I regularly update /usr/src without making a new world or kernel.

If kldload automatically falls back to trying /boot/kernel in
this case then everything would be OK. If kldload does not or
cannot retry then I would not consider this change a good idea.

There's also the possibility that the module is loaded
successfully, but at run time it fails due to missing
functionality in the old kernel. I'm not sure that this could
happen.
--
Gary Jennejohn
Mark Johnston
2017-04-17 19:09:40 UTC
Permalink
Post by Gary Jennejohn
On Sun, 16 Apr 2017 15:12:49 -0700
Post by Baptiste Daroussin
Hi all,
I would like to change in FreeBSD 12 at least the default order the modules are
found/look up.
For now the modules are loaded from /boot/kernel first then if not found,
checked from /boot/modules.
I think we should revert that to /boot/modules first then /boot/kernel.
The problem I see with this is that the module under
/boot/modules may have been generated against a /usr/src which is
newer than what was used to generate the running kernel. In this
case kldload should (I hope) fail.
It may or may not; the load will fail if the running kernel's
__FreeBSD_version does not match the value that the module was compiled
with. If the __FreeBSD_version values match, then the module is in
theory compatible with the running kernel and should just work.
Post by Gary Jennejohn
I regularly update /usr/src without making a new world or kernel.
If kldload automatically falls back to trying /boot/kernel in
this case then everything would be OK. If kldload does not or
cannot retry then I would not consider this change a good idea.
I don't think there's any mechanism to fall back. A
"kldload foo" from the command line will cause the kernel to try and
load the first "foo.ko" found in the paths given by the kern.module_path
sysctl value. If that fails, the kldload fails. I'm not sure how it
works for modules loaded by loader(8).
Post by Gary Jennejohn
There's also the possibility that the module is loaded
successfully, but at run time it fails due to missing
functionality in the old kernel. I'm not sure that this could
happen.
Loading...