[arch-dev-public] out of tree modules and alpm-hooks
Hello, I pushed into community-testing a new version of dkms, with an alpm hook to build oot modules at install time, instead of at startup time with the systemd service. The hooks is very simple; it build and install dkms registered modules for all installed kernel version when a package ending by -dkms is installed or updated. So, installing or updating a *-dkms package (e.g virtualbox-host-dkms or nvidia-340xx-dkms) build and install the shipped modules and allow to use it like the binary package (e.g modprobe nvidia). As a consequence, loading of oot modules at boot are back to modules-load.d logic. If everything works correctly, we could get ride of pre-compiled oot modules packages (e.g virtualbox-host-modules) for linux and linux-lts and offer a unique approach for all kernels (arch, lts, zen, grsec). Do you think we should define a better way to match package which should trigger dkms rebuild? I firstly thought to use a provides=('DKMS_MODULE'), but alpm hooks don't match provides. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On Fri, Feb 19, 2016 at 2:27 AM, Sébastien Luttringer <seblu@seblu.net> wrote:
Hello,
I pushed into community-testing a new version of dkms, with an alpm hook to build oot modules at install time, instead of at startup time with the systemd service.
The hooks is very simple; it build and install dkms registered modules for all installed kernel version when a package ending by -dkms is installed or updated.
So, installing or updating a *-dkms package (e.g virtualbox-host-dkms or nvidia-340xx-dkms) build and install the shipped modules and allow to use it like the binary package (e.g modprobe nvidia).
As a consequence, loading of oot modules at boot are back to modules-load.d logic.
If everything works correctly, we could get ride of pre-compiled oot modules packages (e.g virtualbox-host-modules) for linux and linux-lts and offer a unique approach for all kernels (arch, lts, zen, grsec).
Do you think we should define a better way to match package which should trigger dkms rebuild? I firstly thought to use a provides=('DKMS_MODULE'), but alpm hooks don't match provides.
Cheers,
-- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
What about when you remove a dkms package? Would be nice to remove the build modules as well. With these hooks [1] designed for kernel transaction, we will have complete support of oot modules in pacman. [1] https://github.com/andrewgregory/pachooks/pull/4 Cheers, -- Maxime
On ven., 2016-02-19 at 08:12 +0100, Maxime Gauduin wrote:
On Fri, Feb 19, 2016 at 2:27 AM, Sébastien Luttringer <seblu@seblu.net> wrote: What about when you remove a dkms package? Would be nice to remove the build modules as well. This is done by post install scriplet[1] of each dkms module package (e.g it calls "dkms remove vhosthost/${1%-*} --all").
Name and version of the dkms modules to remove is not easy to guess in a global hook. Also note that a dkms module can build several kernel modules. That's also why registering (dkms add) of the modules is done by install scriplet. Only the build/install of registered modules are done by the hook in order to schedule them properly.
With these hooks [1] designed for kernel transaction, we will have complete support of oot modules in pacman.
I didn't tried them but I don't get how this can works when you install/update a dkms module. Your dkms-install hook is triggered by files installation in /usr/lib/modules, but dkms packages didn't do that at all. They write these files in /usr/src/$foo and register the dkms module with dkms add. Files are copied in /usr/lib/modules when you run "dkms install" (so not under the watch of alpm), so it make no sense to call dkms install again when file are here. [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/nvidia-dkms .install?h=packages/nvidia -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On Fri, Feb 19, 2016 at 4:12 PM, Sébastien Luttringer <seblu@seblu.net> wrote:
On ven., 2016-02-19 at 08:12 +0100, Maxime Gauduin wrote:
On Fri, Feb 19, 2016 at 2:27 AM, Sébastien Luttringer <seblu@seblu.net> wrote: What about when you remove a dkms package? Would be nice to remove the build modules as well. This is done by post install scriplet[1] of each dkms module package (e.g it calls "dkms remove vhosthost/${1%-*} --all").
Right.
Name and version of the dkms modules to remove is not easy to guess in a global hook. Also note that a dkms module can build several kernel modules.
That's also why registering (dkms add) of the modules is done by install scriplet.
Only the build/install of registered modules are done by the hook in order to schedule them properly.
With these hooks [1] designed for kernel transaction, we will have complete support of oot modules in pacman.
I didn't tried them but I don't get how this can works when you install/update a dkms module.
I'm aware of that, they were designed that way. That's why with those, and your hook triggered by dkms package transactions, every case will be covered. I guess it could be possible to handle both within a single hook by adding an additional trigger on "usr/src/*" and so on, but I think it's probably better to keep them separate.
Your dkms-install hook is triggered by files installation in /usr/lib/modules, but dkms packages didn't do that at all. They write these files in /usr/src/$foo and register the dkms module with dkms add.
Files are copied in /usr/lib/modules when you run "dkms install" (so not under the watch of alpm), so it make no sense to call dkms install again when file are here.
[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/nvidia-dkms .install?h=packages/nvidia
-- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77
On ven., 2016-02-19 at 17:47 +0100, Maxime Gauduin wrote:
On Fri, Feb 19, 2016 at 4:12 PM, Sébastien Luttringer <seblu@seblu.net> wrote:
I didn't tried them but I don't get how this can works when you install/update a dkms module.
I'm aware of that, they were designed that way. That's why with those, and your hook triggered by dkms package transactions, every case will be covered. I guess it could be possible to handle both within a single hook by adding an additional trigger on "usr/src/*" and so on, but I think it's probably better to keep them separate.
ok, you want to trigger dkms modules install/uninstall when a kernel is added/upgraded/removed. Make sense. I completely rewrote the hook and the script to manage all features you want in version 2.2.0.3+git151023-4. So, with the last version of the dkms hooking system: - When a kernel package (with headers) is installed, all DKMS modules are installed for this kernel (means built and copied into the new kernel modules tree). Detection is done via alpm-hooks Type=File on /usr/lib/modules/*/build/include. - When a kernel package (with headers) is removed, all DKMS modules are removed for this kernel. Detection is done via alpm-hooks Type=File on /usr/lib/modules/*/build/include. - When a DKMS module package is installed, its kernel modules are installed (means registered in dkms, built, copied into the modules tree) for each kernel with headers on the system. Detection is done via alpm-hooks Type=File on /usr/src/*/dkms.conf - When a DKMS module package is removed, its modules are removed (means unregistered from dkms and removed from the modules tree) of each kernel with headers on the system. Detection is done via alpm-hooks Type=File on /usr/src/*/dkms.conf As dkms do automatically add and build modules when you install them, we don't need anymore to register/unregister dkms modules in post_install/pre_remove. So we'll be able to lighten our dkms modules packages. :) Next steps: - move dkms to extra, as it is pulled by packages in extra (e.g nvidia-dkms) - Drop binary modules of virtualbox (and fix the wrong modules path in /usr/src) Testing and feedbacks of the dkms package in cty-testing is welcome. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
participants (2)
-
Maxime Gauduin
-
Sébastien Luttringer