Skip to content
Snippets Groups Projects

rcg: fix module symvers discovery

Merged Jameson Rollins requested to merge jameson.rollins/advligorts:fix-find-modsym into master
1 unresolved thread

This makes discovery of the Module.symvers happen at model build time, instead of at build tree creation/configuration.

fixes #33 (closed)

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Jameson Rollins changed milestone to %4.0.0

    changed milestone to %4.0.0

  • mentioned in issue #33 (closed)

  • That indeed moves the problem down to 'make' step, and thank you for implementing it.

    But I realized that our existing method (implemented here) is not sufficient, based on testing yesterday a) The dkms status query needs an additional grep using uname -r to pick the record for the kernel in use (straightforward to add) b) These are both static queries, not tracking which kernel module is actually in use. If you install a packaged version of 'mbuf', then want to do an out-of-tree build of 'mbuf' in RCG, the new module is installed and loaded, but the query will still pick up the Module.symvers from the DKMS directories.

    -- If both methods wrote to the same directory, say /usr/src/mbuf/uname -r/unman -m with DKMS on its make and RCG on make install, then it would better track which kernel module is actually loaded. (I think)

  • We should really build the models for all available kernels, not just the one that's currently installed. But I agree it's best to make sure we build against the running kernel for now. I'll update the script appropriately.

    For people building out-of-tree, they can just purge the dkms packages, so I don't think that needs to be specially supported.

    Honestly, what we should really be doing is using DKMS to build the front-end models. The RCG should generate the code, but then leave it to be compiled at "install" time, by DKMS, and recompiled automatically when new kernels are installed. Not only would that make sure we're building against the correct kernel and support module versions, but it would also allows us to do model builds on non-front end machines, and then distribute the code to the front-ends.

  • The first change is needed because the dkms status query returns a separate line for each build of the kernel module (one for kernel ever used). So if you install 'mbuf' with the non-real-time kernel, then switch to the real-time kernel, the dkms status will have two lines in it (not the one) and the parsing won't work.

  • It doesn't matter when you install mbuf, dkms should always build the module for every installed kernel.

    Edited by Jameson Rollins
  • added 1 commit

    • 8121fbdd - rcg: fix module symvers discovery

    Compare with previous version

    • What I meant was that on x2boot2 (before I deleted the non-RT part), the dkms status returned

      controls@x2boot2:/var/lib/dkms/mbuf/4.0.0~dev1$ /sbin/dkms status -m mbuf\
      mbuf, 4.0.0~dev1, 4.19.0-5-amd64, x86_64: installed\
      mbuf, 4.0.0~dev1, 4.19.37-aei-cs, x86_64: installed\

      The existing code only expects one record, not two, so would not look in the correct place (unless the Module.symvers for different kernels are identical.

      Edited by Jameson Rollins
    • This is fixed in the latest version.

    • Please register or sign in to reply
  • merged

  • Rolf Bork mentioned in commit 62701b21

    mentioned in commit 62701b21

Please register or sign in to reply
Loading