| unixist | I'm writing an out-of-tree kernel module that I want to make available in at least ubuntu's repo. Since a module must be built against the same kernel version that is currently running, how do I go about ensuring that the module gets built against all versions of the kernel that are available in ubuntu's repo? I can't quite seem to find the answer on the wiki | 00:11 |
|---|---|---|
| JanC | unixist: use DKMS ? | 01:02 |
| JanC | there are several other packages using DKMS to get kernel modules rebuilt on kernel upgrades, so you can check how they do it | 01:02 |
| unixist | JanC: DKMS looks to build client-side, right? | 01:21 |
| JanC | yes | 01:22 |
| unixist | JanC: Is it not preferable to have the repo itself rebuild the module based upon its dependency being modified? | 01:23 |
| unixist | JanC: I'd like for "apt-get upgrade kernel" to be able to pull in the new module because it was already built when the new kernel was built | 01:23 |
| JanC | that would require that you or the kernel team update your package before every kernel update | 01:25 |
| unixist | JanC: right | 01:25 |
| unixist | I take it something like that doesn't exist? It makes little sense to me to require all clients to have a build environment, the kernel source itself, etc. and to actually perform the build every upgrade | 01:25 |
| JanC | unixist: only the kernel headers (not the source) are needed to build a module | 01:28 |
| JanC | eh | 01:28 |
| JanC | unixist: only the kernel headers (not the source) are needed to build a module, but you would need a build environment, yes | 01:28 |
| JanC | the alternative is that you convince upstream linux or the Ubuntu kernel developers to include your module | 01:29 |
| unixist | JanC: Thanks for the help | 01:38 |
| * unixist goes to ponder | 01:38 | |
| JanC | unixist: maybe some Ubuntu kernel developer can help you further when they are around (many of them aren't around much due to the holidays, I guess) | 01:38 |
| unixist | JanC: Even if I upstream the module, it'd have to be enabled by default, which I would imagine is much harder (if not just a longer road) than just getting it as an opt-in module | 01:39 |
| JanC | unixist: if it's upstreamed, and either useful for a lot of people or unlikely to disrupt other things in the kernel, then getting it enabled in Ubuntu shouldn't be too hard? | 01:42 |
| unixist | JanC: No idea! It was just a pessimistic guess :) | 01:42 |
| unixist | I will probably end up trying | 01:42 |
| unixist | JanC: If you're interested, it's a proof of concept that I've merged into osquery | 01:43 |
| JanC | it's a decision the Ubuntu kernel team would have to make, of course, but compare usefulness (e.g. get some broken hardware to work) vs. the trouble it might cause them or other users | 01:43 |
| unixist | https://github.com/facebook/osquery/tree/master/kernel/linux | 01:43 |
| unixist | It's a security feature, so I think I've to tread lightly | 01:44 |
| JanC | so, sounds like something the security team would want to have their say about too :) | 01:45 |
| unixist | You see why I lean toward pessimism | 01:46 |
| JanC | and something that people who need it probably wouldn't mind installing a build system | 01:46 |
| JanC | so then DKMS would be fine | 01:47 |
| JanC | as having it rebuild automatically on kernel upgrades would improve on manual rebuilding | 01:49 |
| unixist | agreed | 01:50 |
| unixist | JanC: thanks for your help | 01:50 |
| JanC | a DKMS-based package can also be useful to get more testers, and that could also help getting it upstreamed and/or approved by security people, etc. | 01:52 |
| unixist | Yeah, good thought | 01:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!