[arch-dev-public] The /lib/modules/$(uname -r)/updates directory - and how great it is
dpmcgee at gmail.com
Mon Apr 21 17:15:46 EDT 2008
On Mon, Apr 21, 2008 at 2:11 PM, Thomas Bächler <thomas at archlinux.org> wrote:
> 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
Big +1 from me, thanks Thomas.
More information about the arch-dev-public