Modular maintenance and packaging of drivers
a project by mwilck
Updated about 1 month ago. No love. 1 follower.

We currently maintain all drivers in the SUSE kernel tree. While this is a well-established procedure, it also has a number of drawbacks in my opinion. I've been experimenting with a different model, tracking (so far, only one) driver in a separate git repository, and packaging it as kernel module package (KMP). This way of working fits my own mental model of code development better than the quilt style we employ in day-to-day driver maintenance.

I'd like also to experiment with packaging. By separating drivers from the core kernel package, the latter could be made much smaller and builds could be faster, whereas, OTOH, driver updates would be easily done without updating the entire kernel. QA might be quicker, too, as it could focus on just some test areas specific to the driver at hand.

I understand that this pretty much contradicts the SUSE kernel maintenance philosophy. Yet I want to experiment some more, and possibly, some day, be able to provide a PoC. Not this year, though.

Join this project

Looking for hackers with the skills:

Nothing? Add some keywords!

This project is part of:

Hack Week 19

Activity

  • about 1 month ago: mwilck started this project.
  • almost 5 years ago: mwilck originated this project.


    • Comments

    • mwilck
      about 1 month ago by mwilck | Reply

      I'm grabbing this again. At least I want to finish the part of the project which has already matured quite a bit, support for "partial" runs of depmod (for adding or removing just a couple of modules instead of running depmod over everything).

    • mwilck
      29 days ago by mwilck | Reply

      Results of Hackweek '24:

      I took up my previous work on kmod to add support for the "incremental depmod" feature, which I thought I'd finished 3 years ago already. It was just lacking some cleanup and a few more tests, so I thought.

      Unfortunately the kmod project has taken up quite a bit of development momentum recently, after having had a stable period for years. So I had quite some rebasing work to do. Getting the test cases right was also a big challenge. Even more so after enabling the kmod CI on GitHub, which runs on multiple different distributions that all differ significantly from my environment (openSUSE Leap), causing the tests that completed just fine on Leap to fail on those distros. In the process, I actually discovered a few very old bugs in the existing kmod code base.

      Anyway, by the end of the week I've been able to create a PR which actually received some positive feedback, although it's rather large and from a person that hadn't contributed to the kmod project previously.

      Let's wait and see what comes out of it.

    Similar Projects

    This project is one of its kind!