You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey @congwang-mk
Thanks a lot for your great work on KScript. I can work on this feature incrementally and slowly over the summer. Do you have any suggestions or a good starting point? As I "promised" during AgenticOS'26, to contribute to the project.
Hi @Kenan-Kamel — thanks again, great to hear from you after AgenticOS'26.
Quick reframe on the design before you dig in. There are really two pieces here:
1. A CLI workflow for the lifecycle:
kernelscript deploy app.ks --name foo # initial install, pins to /sys/fs/bpf/foo/
kernelscript update foo app_v2.ks # swap the running instance
The pin tree under /sys/fs/bpf/<name>/ is the canonical record of a running instance — no daemon needed.
2. Language support for map migrations — and this is the part I think is most interesting. Program code can be swapped atomically with bpf_link__update_program, but if the new .ks changes a map's key/value shape, that map has to be recreated, and the old contents need to be migrated explicitly. Rather than handle this with a CLI flag, I'd like the language itself to express it — something like:
@migrate(flows)
fn migrate_flows(old: hash<u32, OldStats>, new: hash<u32, NewStats>) {
for (k, v) in old {
new[k] = NewStats { count: v.count, bytes: 0 }
}
}
The compiler refuses to compile a new version if a map's shape changed and no @migrate exists. The CLI then invokes the handler between loading the new program and atomically attaching it. Old map schema can be recovered from BTF on the bpffs pin, so the user doesn't have to ship the old .ks.
Suggested phasing for incremental summer work:
kernelscript deploy + pinning (single-program XDP). Smallest useful unit.
kernelscript update for the transparent case — same map shapes, program-only swap.
@migrate syntax + type checker enforcement (pure compiler work).
Wire migrations into the update flow — codegen + CLI invocation.
Each phase is independently shippable. Before code, I'd love a short design note from you in this issue covering: (a) exact CLI surface and pin layout, (b) @migrate syntax and what counts as a "breaking" map change, (c) error/rollback behavior when a migration fails partway. That lets us iterate cheaply.
Happy to sync if useful — otherwise this thread works.
Thanks @congwang-mk,
I will dive deeper into the code for a few weeks and post/create a design note before I start writing code for each phase, as you suggested. The plan is clear and straightforward; it lists any possible additions in the design notes.
Thanks @congwang-mk, I will dive deeper into the code for a few weeks and post/create a design note before I start writing code for each phase, as you suggested. The plan is clear and straightforward; it lists any possible additions in the design notes.
Activity
Kenan-Kamel commentedon May 25, 2026
Hey @congwang-mk
Thanks a lot for your great work on KScript. I can work on this feature incrementally and slowly over the summer. Do you have any suggestions or a good starting point? As I "promised" during AgenticOS'26, to contribute to the project.
-Kenan (University of Illinois Chicago)
congwang-mk commentedon May 26, 2026
Hi @Kenan-Kamel — thanks again, great to hear from you after AgenticOS'26.
Quick reframe on the design before you dig in. There are really two pieces here:
1. A CLI workflow for the lifecycle:
The pin tree under
/sys/fs/bpf/<name>/is the canonical record of a running instance — no daemon needed.2. Language support for map migrations — and this is the part I think is most interesting. Program code can be swapped atomically with
bpf_link__update_program, but if the new.kschanges a map's key/value shape, that map has to be recreated, and the old contents need to be migrated explicitly. Rather than handle this with a CLI flag, I'd like the language itself to express it — something like:The compiler refuses to compile a new version if a map's shape changed and no
@migrateexists. The CLI then invokes the handler between loading the new program and atomically attaching it. Old map schema can be recovered from BTF on the bpffs pin, so the user doesn't have to ship the old.ks.Suggested phasing for incremental summer work:
kernelscript deploy+ pinning (single-program XDP). Smallest useful unit.kernelscript updatefor the transparent case — same map shapes, program-only swap.@migratesyntax + type checker enforcement (pure compiler work).Each phase is independently shippable. Before code, I'd love a short design note from you in this issue covering: (a) exact CLI surface and pin layout, (b)
@migratesyntax and what counts as a "breaking" map change, (c) error/rollback behavior when a migration fails partway. That lets us iterate cheaply.Happy to sync if useful — otherwise this thread works.
Kenan-Kamel commentedon May 27, 2026
Thanks @congwang-mk,
I will dive deeper into the code for a few weeks and post/create a design note before I start writing code for each phase, as you suggested. The plan is clear and straightforward; it lists any possible additions in the design notes.
-Kenan
congwang-mk commentedon May 27, 2026
Please feel free to suggest better idea.