Uptream kernel module?

[brianjmurrell]

Question

I wonder if there has ever been an attempt to upstream the kernel module.

Motivation

Easier project maintenance as well as deployment and admin. Perhaps get more visibility and exposure if the module is just there already in everyone's distro's kernels.

Your Environment

EL8 and soon EL9

[robertbaldyga]

Hi @brianjmurrell ! This was considered as an option number of times, and there is a list of reasons why we deliberately decided to stay out-of-tree module. Here you have at least some of them:

1. Broad kernel version coverage. This may sound counterintuitive, as being upstream automatically makes the module available on any kernel, but it's only starting from the version to which it was merged (and Open CAS supports currently 3.10+).
2. Availability of the most recent version. Kernel users are stuck with module version available in the kernel version they use, unless they do backporting on their own, which is significantly higher entry barrier than installing out-of-tree module from on the GitHub.
3. More control over the release cycle. We develop new features at our own pace and decide which patches are mature enough to be merged into the next release. We have our own extensive test suite, but we are resource constrained, so having flexibility is essential to deliver good quality software product.
4. Open CAS Linux is just a wrapper for OCF, and such an external dependency is unseen (and most likely unwelcome) in upstream Linux kernel module. And having OCF as our central environment-agnostic library is important, because we also maintain integration in SPDK. There are also companies who have their own custom OCF integrations.
5. Maintaining ABI compatibility between kernel and userspace is troublesome. As an out-of-tree project we can always deliver bundle of kernel module and user space tools, so that compatibility is not an issue.
6. Maintaining cache metadata compatibility is crucial. Being out-of-tree and supporting wide range of kernel versions we are letting users to do an Open CAS version upgrade when it's convenient to them. Thanks to that we have more flexibility, as preserving metadata format between the versions is not necessary.
7. BSD license is important, especially on the OCF side, as it's intended to be integrated deeply into a software stack, and is some cases GPL may not be acceptable. SPDK integration is one of the examples.
8. There are already block storage caching solutions present in Linux kernel. If some users prefer using them, we are ok with that. If not, then we hope Open CAS is a right alternative for them.