OtherU's hardware work needs a kernel development path that is boring in the right places. External modules let a team build hardware-facing code outside the kernel tree, but that code still has to match the running kernel's configuration, headers, compiler flags, and exported-symbol expectations. Linux kbuild is what keeps that work from turning into a pile of one-off build scripts.
Why kbuild instead of custom scripts
The kernel documentation is explicit about it: modules need the kernel build system to stay compatible with build-infrastructure changes and to pick up the correct compiler behavior.
That matters anywhere Hermes depends on hardware bridges, capture devices, GPU instrumentation, or host-level control surfaces. A module that compiles once is not enough. It has to still make sense when the kernel, the distro package, or the hardware stack moves.
What a clean workflow looks like
A good external-module workflow is a small set of repeatable commands. Build against the kernel tree with M=$PWD, install through the module target, and keep generated artifacts out of the source boundary.
None of that is glamorous, and that is the point. It gives CI a stable contract: prepare headers, build the module, record the kernel release, run load tests, and reject artifacts that do not match the deployed host.
Symbol versioning as a guardrail
Module.symvers and module versioning matter more here than they might elsewhere. With CONFIG_MODVERSIONS in play, symbol CRCs act as a simple ABI consistency check.
That is the guardrail this kind of infrastructure needs. The system should fail loudly when a module was built against the wrong kernel shape, rather than producing a vague runtime fault later, after an agent has started touching hardware.
External modules are still kernel code
Using kbuild does not make kernel work low-risk. A bad pointer, a race, a wrong DMA assumption, or a mismatched header can still take the machine down.
So isolate development hosts, run stress tests before promotion, collect dmesg and tracing output, and keep rollback instructions next to the artifact. Module loading should be an operator-approved deployment step, not something an agent does casually.
What to capture for audit
Each build should record the kernel release, compiler version, configuration source, Module.symvers status, module hash, and test result.
Hermes can surface those facts in an operator view before a module loads. That is usually enough context for a reviewer to tell a routine rebuild from a risky change at the hardware boundary.
Rollback
Kernel-adjacent work needs an uninstall path, a known-good module package, and a host recovery procedure that does not depend on the agent being healthy.
Kbuild supplies the standard build contract. Wrapping that contract in CI, documentation, and human approval is still OtherU's job.