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.

Looking for hackers with the skills:

Nothing? Add some keywords!

This project is part of:

Hack Week 19

Activity

  • 11 days ago: mwilck started this project.
  • almost 5 years ago: mwilck originated this project.

  • Comments

    • mwilck
      11 days 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).

    Similar Projects

    This project is one of its kind!