Rebuild cplayground's patched kernel under a custom "flavour" name (e.g. generic, lowlatency) via the Debian build system (I used "cplayground"), thus affecting uname output to indicate the patched state. Fixes #19. There are no substantive changes in the new flavour, only the name, although files are created in which we could fairly trivially change e.g. kernel config parameters.
Uname output: Linux vagrant 5.3.0-62-cplayground #56~18.04.1 SMP Thu Jul 9 18:50:58 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Most of these steps are based on this AskUbuntu thread, using debian.hwe instead of debian.master because the latter had no effect in the source package I was using.
Troubleshooting and trying to understand the process brought me here, here, and here. (I post these links mostly for future travelers who may be trying to build custom flavour of Debian kernel, build custom flavour of Ubuntu kernel, modify Ubuntu kernel version string, modify Linux flavour, modify Linux version string, modify Linux uname output, etc etc.)
As happy as I am that this works, there are a few caveats with what I've uploaded / things I'm not happy with:
The debfiles I uploaded aren't actually outputs of the script, the script is an encoding of the steps I followed while producing these debfiles, minus a teensy bit of flavoring in a description string.
As I understand, all those skip flags at the end of the build process (see the last "here" link above) are skipping sanity checks, which doesn't make me happy. Since the substance of the patch is relatively trivial, I'm not too worried, and the kernel boots and runs which means it's probably fine (TM), but fixing this would require further investigation.
This locks us into x86_64, although the changes to avoid that should (TM) be fairly trivial.
The build process, at least when I ran it, exited with an error I did not understand, but produced all the debfiles I was expecting. Technically these artifacts are the results of a failed build :smiley_cat:.
The build script isn't tested on a clean system.
I have not rigorously tested the resulting VM image (master branch + this kernel, vagrant up). In particular flooding the system with processes as was done to test the kernel module in this blog post might be a good idea. I have only verified that the server runs and that the hello world program shows the file descriptors I expect it to.
As an aside, a friend of mine who I've been talking to about this thinks that the kernel module's interface to the files_struct might be safely doable with only RCU locks, not needing the symbol exports which necessitate our patch. I'm not fully convinced, but this is something I will looking into, and if it pans out and we can avoid needing a custom kernel altogether, I assume that would be a good thing.
Rebuild cplayground's patched kernel under a custom "flavour" name (e.g. generic, lowlatency) via the Debian build system (I used "cplayground"), thus affecting
unameoutput to indicate the patched state. Fixes #19. There are no substantive changes in the new flavour, only the name, although files are created in which we could fairly trivially change e.g. kernel config parameters.Uname output:
Linux vagrant 5.3.0-62-cplayground #56~18.04.1 SMP Thu Jul 9 18:50:58 UTC 2020 x86_64 x86_64 x86_64 GNU/LinuxMost of these steps are based on this AskUbuntu thread, using debian.hwe instead of debian.master because the latter had no effect in the source package I was using.
Troubleshooting and trying to understand the process brought me here, here, and here. (I post these links mostly for future travelers who may be trying to build custom flavour of Debian kernel, build custom flavour of Ubuntu kernel, modify Ubuntu kernel version string, modify Linux flavour, modify Linux version string, modify Linux uname output, etc etc.)
As happy as I am that this works, there are a few caveats with what I've uploaded / things I'm not happy with:
vagrant up). In particular flooding the system with processes as was done to test the kernel module in this blog post might be a good idea. I have only verified that the server runs and that the hello world program shows the file descriptors I expect it to.As an aside, a friend of mine who I've been talking to about this thinks that the kernel module's interface to the
files_structmight be safely doable with only RCU locks, not needing the symbol exports which necessitate our patch. I'm not fully convinced, but this is something I will looking into, and if it pans out and we can avoid needing a custom kernel altogether, I assume that would be a good thing.