On Wed, Nov 8, 2017, at 12:44 PM, Stephen Milner wrote: > On Wed, Nov 8, 2017 at 11:33 AM, Dusty Mabe <du...@dustymabe.com> wrote: > <snip/> > > Really you have two options. > > > > 1. unlock your ostree and install the rpms > > 2. build the kernel module for the kernel you are targeting and deliver via > > a system > > container like in https://github.com/giuseppe/hellomod > > I like the idea of using system containers as a way of providing > kernel modules like these. Since system containers are not meant to be > scheduled they end up working more like a package which fits the bill.
I think a bifurcation here is probably around CentOS vs Fedora/other - CentOS gets a lot of the RHEL kABI, so it can work OK to just carry forward a binary module. Could that module live in a container? Probably, though it's not clear to me what that'd gain over dropping it in /usr/local/lib/modules or whatever? We do have container signing at least? But the reason dkms exists is for the Fedora and other case, to at least *try* to build from source when the host kernel is upgraded. That gets more into the "needs to be integrated with host updates" case. The https://github.com/src-d/coreos-nvidia approach is basically "dkms in a container" which seems like a sane short term, but the problem with it is you have to wait on bootup for the module to build, and if it fails to build, you only find out on boot. (I'll be honest I am mostly just talking about this having glanced at README.md files and a little bit of code, I haven't actually used a 3rd party kernel module in a long time; I could be partially or completely wrong about some of the details)
