[arch-dev-public] The /lib/modules/$(uname -r)/updates directory - and how great it is
The module-init-tools have had this feature for a while and I just wanted to tell you about how we can use it: The modules contained in the updates/ subdirectory in your module directory are always preferred over any other modules. Thus, you can put updated modules into it which supercede the ones installed by our kernel. This is great, I'll just give some examples: - The compat-wireless package uses it That's how I know about it. compat-wireless puts a complete new mac80211 tree with drivers into updates/. This means it is easy to get updated wireless drivers without conflicting with the stock kernel and without having to rebuild the whole kernel. - ALSA updates ALSA has been known to be a bitch. Sometimes the drivers in the stock Linux kernel are out of date and an updated driver will help. Now, we could provide a PKGBUILD via AUR which installs the latest ALSA drivers to updates/ - this would give a user the possibility to use an updated alsa without having to rebuild the kernel, conflict with the kernel or having to delete files and confuse pacman. - Random patches to drivers It has happened that users wanted a particular feature enabled or changed in a particular driver. There is the phc undervolt patch and there is some toshiba-bluetooth patch still in our kernel. Now I don't like forcing patched drivers on people who don't need it, and generally, our community likes vanilla kernels more. With the updates/ directory it is possible to provide these special cases via PKGBUILDs/AUR - provided the change is only in the module(s) in question, one could patch it, build it and put it into the updates/ directory. Without having a patched kernel, the users could be happy - again, no kernel rebuilding or hacky conflicting. (In the above cases, only the acpi-cpufreq resp. the toshiba-acpi modules are modified ... nothing is modified in the kernel itself). I already plan to maintain compat-wireless as a binary package. I will also put an alsa-driver-updates package into the AUR. And I will try to package the modified toshiba-acpi module so I can drop the patch from the kernel (I will also put this in AUR then). I hope this will make life easier for us and for many users in our community - it is a much cleaner thing than patching the kernel all the time.
On Mon, Apr 21, 2008 at 2:11 PM, Thomas Bächler
The module-init-tools have had this feature for a while and I just wanted to tell you about how we can use it:
The modules contained in the updates/ subdirectory in your module directory are always preferred over any other modules. Thus, you can put updated modules into it which supercede the ones installed by our kernel. This is great, I'll just give some examples:
- The compat-wireless package uses it That's how I know about it. compat-wireless puts a complete new mac80211 tree with drivers into updates/. This means it is easy to get updated wireless drivers without conflicting with the stock kernel and without having to rebuild the whole kernel.
- ALSA updates ALSA has been known to be a bitch. Sometimes the drivers in the stock Linux kernel are out of date and an updated driver will help. Now, we could provide a PKGBUILD via AUR which installs the latest ALSA drivers to updates/ - this would give a user the possibility to use an updated alsa without having to rebuild the kernel, conflict with the kernel or having to delete files and confuse pacman.
- Random patches to drivers It has happened that users wanted a particular feature enabled or changed in a particular driver. There is the phc undervolt patch and there is some toshiba-bluetooth patch still in our kernel. Now I don't like forcing patched drivers on people who don't need it, and generally, our community likes vanilla kernels more. With the updates/ directory it is possible to provide these special cases via PKGBUILDs/AUR - provided the change is only in the module(s) in question, one could patch it, build it and put it into the updates/ directory. Without having a patched kernel, the users could be happy - again, no kernel rebuilding or hacky conflicting. (In the above cases, only the acpi-cpufreq resp. the toshiba-acpi modules are modified ... nothing is modified in the kernel itself).
I already plan to maintain compat-wireless as a binary package. I will also put an alsa-driver-updates package into the AUR. And I will try to package the modified toshiba-acpi module so I can drop the patch from the kernel (I will also put this in AUR then).
I hope this will make life easier for us and for many users in our community - it is a much cleaner thing than patching the kernel all the time.
Big +1 from me, thanks Thomas. -Dan
Awesome. +1
participants (3)
-
Dan McGee
-
James Rayner
-
Thomas Bächler