Provisioning · Reproducibility

Run knlp with kdevops.

knlp applies Linux-kernel development methodology to ML research, so it ships as a first-class kdevops workflow. If you already use kdevops to stand up bare-metal, cloud, or virtual machines, you can provision a node and bring up a reproducible knlp checkout with a couple of make commands — the same Kconfig-driven bringup you use for kernel test workflows.

kdevops plugin v1.0.0 Kconfig-driven bringup bare metal / cloud / VM

What you get

kdevops provisions the machine (your choice of bare metal, a cloud provider, or local virtualization), then a knlp bringup step clones the repository to a data path of your choosing and installs its Python requirements into a virtualenv. From there the machine is ready to run knlp's Kconfig experiments — for example the code-reasoning harness or the GPT-2 ablations — with the same reproducible make defconfig-… && make flow knlp uses everywhere.

Requires kdevops ≥ 5.0.0 (the release that added the versioned plugin system). knlp is packaged as a dedicated workflow plugin — its manifest lives in the repo at .kdevops/plugin.yaml.

Option A — install as a plugin (recommended)

knlp carries its own kdevops packaging under .kdevops/, so kdevops can install it directly from GitHub as a versioned, taint-tracked plugin. From your kdevops checkout:

# add the knlp plugin (GitHub tarball fetch; add REF=<tag> to pin a version)
make kdevops-plugin-add URL=https://github.com/mcgrof/knlp

# select a base machine config plus the knlp workflow, then build + bring up
make defconfig-<your-base>+knlp
make
make bringup

The plugin installs to ~/.config/kdevops/plugins/knlp/ and is wired into the build system through generated Kconfig.plugins / Makefile.plugins. Because plugin content is externally maintained, kdevops marks the configuration as tainted so it's clear which parts came from outside the tree. Pin a release with REF=<git tag or branch> for reproducibility.

Option B — as a user-private workflow

If you'd rather not use the plugin manager, kdevops ships a complete worked example you can copy into your user config. From your kdevops checkout:

# copy the example knlp workflow into your user config dir
mkdir -p ~/.config/kdevops
cp -r docs/user-workflows/example-knlp/* ~/.config/kdevops/

# the +knlp fragment enables user-private workflows and the knlp workflow
make defconfig-<your-base>+knlp
make
make bringup

User-private workflows live in ~/.config/kdevops/ and let you keep custom workflows outside the kdevops tree entirely. The example is the same content the plugin installs; it's the right starting point if you want to adapt the workflow to your own fork or branch.

What bringup does, and the knobs

The knlp role clones the repo and installs its requirements; the node/host generation tasks stand up the machine kdevops will run it on. The workflow exposes a few Kconfig options (under knlp ML research workflow configuration in menuconfig):

OptionDefaultWhat it sets
WORKFLOW_KNLP_GIT_URL…/mcgrof/knlp.gitwhich repository to clone
WORKFLOW_KNLP_GIT_REFmainbranch, tag, or commit to check out
WORKFLOW_KNLP_DATA_PATH/data/knlpwhere knlp is cloned and installed
Bringup installs knlp's requirements.txt into a virtualenv. For an AMD GPU target, install a ROCm PyTorch wheel instead of the default CUDA build — see the note at the top of knlp's requirements.txt. The plugin provisions and checks out; you pick the accelerator stack for the node.

References

← All knlp research