-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adapting modulus for general-purpose kernel module compilation #5
Comments
@PaulCapestany thank you for the kind words! Unfortunately, we ran out of time and weren't able to discuss that slide during the presentation. The discussion would have centered around the acrobatics needed to run developer container in another container. Specifically, the developer container is distributed as a raw disk image complete with GUID partition table and extra partitions that must either be skipped with an offset or be truncated. This image must then be mounted and chrooted. With regards to your main question: yes, Modulus can absolutely be used to compile and install other kernel modules; in fact, it was deliberately designed this way. NVIDIA just happened to be the first one I needed and implemented. Modulus follows a plugin approach so that implementing compilation for any kernel module X means simply creating a directory I too have run into issues with the developer container size particularly when trying to re-use the developer container. In order to circumvent this issue two things come to mind:
What do you think? For context, the |
@squat nice--I hoped/thought so but wanted to sanity-check; this is great to hear :)
Yes, I have some toy-example-ish modules that I've been trying to get working (since afaict) being in-tree they seemed like they should be straightforward enough... I'm not sure if they'd directly be of interest to anyone else, however, getting them working would theoretically also show folks how to get other in-tree modules working? Re: the particular module(s)--specifically, the ones I've been trying to get working have been Apple-hardware-specific modules such as apple_gmux, applesmc, etc. I've had a bare-metal CoreOS Container Linux HA k8s cluster set up via typhoon running for a while consisting of old Apple laptops, Mac Minis, Mac Pros, etc, which had previously been sitting unused/decommissioned, and it could be cool (but definitely not critical) to have more control/access over their hardware via the requisite kernel modules. Regardless, I'd think that sorting out a good way to get any/other in-tree module(s) working via modulus would probably prove useful to people and I'd be happy to try helping contribute to those ends either way.
Approach 1. seemed like the obvious/easy route, but approach 2. sounds interesting if there might be situations where people would need somewhat unbounded space for compilations. Other than the observation that 1. seems superficially simpler, and that 2. might be more future-proof, I personally don't have very strong opinions in favor of one vs the other--which of them currently seems more compelling to you? |
Ok, @squat thanks so much for clarifying the partition/truncation stuff, I think I got things working with a bigger base image. Just went with quick and dirty resize via Currently AFK but I finally have my in-tree modules compiling away without running out of space, could post more later, thanks again for your help :) |
@PaulCapestany that’s great! Would you consider contributing the changes in a PR? It would be great to include the image resizing as well as any of the new kernel modules you are working on. |
Sure thing. Should be able to shoot off a PR later today/tomorrow |
@PaulCapestany I'll close this for now since we don't have any blockers or issues. |
First off, just wanted to say thanks for this awesome repo and your KubeConEU presentation Lucas!
Quick side-question: at the 12:49 timestamp in the video of your talk, you briefly have a slide up showing the
gdisk -l coreos_developer_container.bin
command and mention that you'd come back to it if there was time. Looks like there wasn't time, or was the topic covered elsewhere?Main question: (perhaps relatedly) it seemed like modulus might be a great way to automatically compile other (non-nvidia) modules for those of us running Kubernetes on CoreOS Container Linux, but, the 2.9G size of the chroot appears to end up being a bottleneck. I've been bumping against
Fatal error: [...] No space left on device
errors while playing around trying to adapt modulus to compile some in-tree kernel modules. It's unclear to me what the specific purpose of thetruncate_bin()
function is, and/or whether the dev container image base size could easily be made bigger in order to have more free space for compiling other modules? Would an approach along those lines make sense for folks interested in general-purpose automatic kernel module compilation, or is that barking up the wrong tree?The text was updated successfully, but these errors were encountered: