Skip to content

Move distribution specifics into the config #328

Description

@evelikov

As mentioned previously #323 (comment), ideally dkms will not know (or care) about the distribution it's run against.

Any specifics like DEST_MODULE_LOCATION overrides will be set in /etc/dkms/framework.conf and the user can override those with the usual /etc/dkms/framework.conf.d mechanism.

For this task, we should:

  • construct a list of distro specific derivation(s), for each
  • check if it's applicable - eg. do we need the collisions/archival for non Debian/Ubuntu platforms
  • add a toggle in framework.conf, honour that in dkms
  • add make install-foo variant which produces creates/uses the correct config for the given distribution

Nice to have:

  • check with existing distros, if they use all the install-foo files, update as necessary
    • eg. Arch uses make install and manually removes kconf files and libdir

Activity

  1. evelikov commented on Aug 15, 2023

    @evelikov
    CollaboratorAuthor

    From #329 we're currently running rpm indiscriminately which is causing problems. We should either:

    • remove the offending calls, or
    • use a conf knob to control that
  2. evelikov commented on Aug 15, 2023

    @evelikov
    CollaboratorAuthor

    Another set of distro specific variations - module signing. In particular:

    • location of sign-file and MOK key/cert
    • deviation across Ubuntu/Debian of the update-secureboot-policy tool

    At a glance, if we are to use modules_install itself aka #319 then we won't need to care about this.

  3. evelikov commented on Aug 15, 2023

    @evelikov
    CollaboratorAuthor

    Moving the original module/collisions to standalone location:

    • on all distros apart from Debian/Ubuntu we backup the original module (on build) and restore it on uninstall

    Might be worth tracking down the reason behind this variance and removing it, in the mid/long run. At least initially preserving the behaviour seems like a good first step.

  4. evelikov commented on Aug 15, 2023

    @evelikov
    CollaboratorAuthor

    The above are the distro-specific variations we have so far, although others may emerge at some point.

    They don't have to be fixed all together/in a single PR. So if anyone is bored and like to write some bash - patches welcome o/

  5. HanabishiRecca commented on Aug 15, 2023

    @HanabishiRecca

    Moving the original module/collisions to standalone location:

    • on all distros apart from Debian/Ubuntu we backup the original module (on build) and restore it on uninstall

    Might be worth tracking down the reason behind this variance and removing it, in the mid/long run. At least initially preserving the behaviour seems like a good first step.

    It is very unclear why. The kernel simply traverses filesystem in alphabetic order, afaik. Which means not removing the original module leads to undefined behavior.
    updates is lower than all existing kernel tree dirs except virt. I.e. it will never replace original modules except they are in virt.

  6. evelikov commented on Aug 15, 2023

    @evelikov
    CollaboratorAuthor

    @HanabishiRecca the original is stored outside of the normal search path. Note that the kernel does not care about any of this - kmod does all the path/priority handling as well as loading.

    The ultimate goal here is not to fix everything that's off with dkms, but migrate from a bunch of "running_distribution" hacks to a data/config driven flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions