Pith. sign in

REVIEW 3 major objections 5 minor 30 references

KernelScript claims that the cross-boundary relationships in an eBPF application — shared map types, program lifecycle, and execution domains — can be unified in one typed DSL whose compiler rejects at compile time bugs that standard C/libb

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-07-31 23:35 UTC pith:NMJ72L3S

load-bearing objection A solid, well-scoped DSL paper with an honest partial evaluation — but the abstract's universal claim about what C/libbpf still loads outruns the evidence. the 3 major comments →

arxiv 2607.23900 v1 pith:NMJ72L3S submitted 2026-07-27 cs.PL cs.OS

KernelScript: Cross-Boundary Typed DSL for eBPF Applications

Cong Wang , Siyuan Sun , Yusheng Zheng This is my paper
classification cs.PL cs.OS
keywords eBPFdomain-specific languagestatic typingcross-boundary correctnesslibbpfXDPprogram lifecyclemap typing
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

KernelScript argues that the bugs eBPF developers hit at the kernel/userspace boundary are not random mistakes but duplicated information: a map declaration, a program handle, and an execution domain each appear in multiple places that nothing checks against each other. The paper's thesis is that a type system can unify those copies, so a developer writes the kernel program, userspace loader, maps, and ring buffers in one source, and the compiler rejects mismatches before code generation. A sympathetic reader cares because the alternative is silent corruption: C/libbpf will build and load a program that reads the wrong packet fields, truncates a map update, or reinterprets a lookup as the wrong type, and only runtime observability reveals it. If right, KernelScript turns that class of failures into compile-time diagnostics while keeping the standard clang/bpftool/libbpf toolchain and near-handwritten performance.

Core claim

KernelScript's central discovery is that the cross-boundary structure of an eBPF application — which map key/value types the kernel and userspace agree on, which execution domain a function runs in, and whether a program has been loaded before it is attached — is duplicated information that a single type system can unify. The compiler types maps, program handles, and execution domains in one source, then emits eBPF C, userspace C, and a Makefile that go through the standard clang/bpftool/libbpf toolchain. The paper's demonstrated claim is that three representative bug classes — a wrong context signature, a map value size mismatch, and a map lookup reinterpreted as an unrelated type — are rej

What carries the argument

The central mechanism is a typed model that separates a FunctionRef (a reference to an eBPF entry-point function) from a ProgramHandle (a loaded program), so that only load() produces a ProgramHandle and attach-before-load becomes a type error rather than a runtime failure. Around that sits a typed map declaration such as var m : hash<K,V>(N), which one descriptor compiles into both a kernel SEC(".maps") definition and userspace accessor functions, and execution-domain attributes (@xdp, @tc, @probe, @tracepoint, @perf_event, @helper, @kfunc) that constrain context types, return types, and illegal crossings between kernel and userspace functions.

Load-bearing premise

The load-bearing premise is that KernelScript's type checker corresponds exactly to what real clang/bpftool/libbpf does — every rejection matches C that builds and loads, and every acceptance matches C that behaves correctly — yet the evaluation tests only 3 of 31 rejections against the C/libbpf counterfactual and documents the toolchain boundary itself drifting.

What would settle it

Run a differential test suite: for each program in the rejection corpus, compile the equivalent C with clang and load it with libbpf; the claim holds only if every rejected KernelScript program corresponds to a C program that builds and loads and reproduces the runtime bug, and every accepted program generates C whose behavior matches hand-written code under traffic or BPF_PROG_TEST_RUN. A single accepted program whose generated C diverges from hand-written behavior, or a C/libbpf bug that KernelScript fails to reject, would settle the claim negatively.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Developers get compile-time diagnostics for wrong context signatures, map key/value mismatches, and illegal domain crossings, instead of silent runtime corruption or verifier rejections.
  • A unified source removes the need to keep kernel C, userspace C, and generated headers synchronized; the five cross-boundary changes in the evaluation required no manual kernel/userspace/header synchronization, with a median of 6 changed lines versus 30 for C/libbpf.
  • Generated code stays on the standard clang/bpftool/libbpf path, so existing build tools and debugging workflows carry over; measured overhead is within run-to-run variance (5 ns vs 6 ns per XDP invocation, 17.25 vs 17.34 Gbps for a counter workload).
  • The same typed model covers a broad application surface — XDP, TC, kprobe, tracepoint, perf_event, maps, ring buffers, tail calls, kfuncs, and struct_ops — in one framework rather than per-use-case DSLs.
  • Because the DSL compiles to inspectable, idiomatic C, teams can adopt it incrementally and still read and debug the generated artifacts.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The design suggests a general recipe for other kernel-extension boundaries: identify duplicated declarations that cross a trust boundary and let one typed declaration generate both sides; the same ratio of caught bugs to code shrinkage may apply to interfaces like seccomp or io_uring.
  • The compile-time guarantee is only as strong as the compiler's model of libbpf behavior; a natural next test is differential testing — generate C for a broad corpus, compile and load both sides, and compare runtime behavior — to catch drift at the toolchain boundary like the bpftool/libbpf version mismatch the paper itself documents in its compatibility evaluation.
  • The FunctionRef/ProgramHandle distinction is a lightweight typestate; extending it to track attach/detach states or handle leaks would turn more runtime failures into compile errors, at the cost of more complex types.
  • Because one source function can be dispatched to either the eBPF or userspace backend, the same approach could in principle target other kernels or runtimes that accept C-like extension programs, though the paper does not claim this.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. KernelScript is a compiled DSL for eBPF applications that unifies kernel-side eBPF C, the userspace loader, and shared map declarations in one source. The type system assigns execution domains to functions (@xdp, @tc, etc.), types maps as hash<K,V>(N), and distinguishes FunctionRef from ProgramHandle to enforce the ordering constraint load ≺ {attach, detach}. The compiler emits eBPF C, userspace C, and a Makefile, preserving the standard clang/bpftool/libbpf pipeline. The evaluation reports 31 buggy programs rejected at compile time with matching diagnostics, 3 of which are additionally shown to build and load under C/libbpf and to exhibit the corresponding runtime corruption; a five-change diff study showing median 6 vs 30 changed LOC; and a compatibility/performance study on 43 repository examples, including 27 XDP programs run on a real kernel. The paper concludes that KernelScript catches cross-boundary bugs before the verifier or runtime, shrinks the cost of cross-boundary changes, and remains compatible with the existing toolchain.

Significance. If the central claim held in full generality, KernelScript would be a useful practical contribution: it replaces hand-written synchronization of map types, program handles, and execution domains with a lightweight typestate model, and it is evaluated against the real clang/bpftool/libbpf toolchain rather than in simulation. The three fully counterfactual cases in Table 1 are positive evidence that some silent runtime corruptions — wrong context fields, truncated map values, native-endian reinterpretation — can become compile-time errors. The performance measurements (generated vs hand-written XDP at 17.25 vs 17.34 Gbps counters, and 5 vs 6 ns per invocation) suggest that the unification does not come at a runtime cost. The paper also honestly documents the toolchain-skew failure it encountered (bpftool 7.7 output vs libbpf 1.3.0). However, the generality of the headline comparative claim is not established by the evidence as reported.

major comments (3)
  1. [Abstract; §5.1 (Table 1)] The headline claim — “KernelScript rejects cross-boundary bugs at compile time that standard C/libbpf still builds and loads” — is counterfactually verified for only 3 of the 31 rejection-suite programs. The remaining 28 are shown only to be rejected by KernelScript; no C/libbpf build/load test is reported. This matters because several listed categories in the 28 would not survive the C/libbpf path: “42+true” is a type error in C, a “600-byte stack” is rejected by clang or the verifier, and lifecycle cases such as load("string") may fail at libbpf runtime rather than at compile/build/load. As reported, the universal claim outruns the data. Please either run the C/libbpf counterfactual for all 31 (or a clearly specified representative sample), or restrict the headline claim to the three verified cases and describe the remaining 28 as compiler-internal rejection tests.
  2. [§1; §2; §3] The motivation cites “code that attaches before populating a map compiles without error” as a cross-boundary invariant that existing tools leave implicit (§1, §2). KernelScript’s type system does not address this invariant: §3 defines only load ≺ {attach, detach} and explicitly excludes path-sensitive properties such as use-after-detach. There is no rule relating map-population operations to ProgramHandle state, so attach-before-populate remains a type error in no sense. The paper should either add a rule for this ordering or state clearly that the attach-before-populate example is not in the system’s scope. The current text invites the reader to infer that the motivating problem is solved.
  3. [§4] The implementation section says that for “fast-moving interfaces, include and extern declarations provide a fallback to raw headers.” This fallback is not described further, and it is unclear whether the type checker sees through such declarations. If a developer uses the fallback for a map or event type, the cross-boundary typing guarantees of §3 may no longer hold; the guarantee would then depend on the developer’s raw headers staying consistent across the boundary. The paper should either restrict the fallback to declarations that do not affect cross-boundary typing or explicitly state which checks are lost when it is used. Without this clarification, the scope of the central compile-time guarantee is ambiguous.
minor comments (5)
  1. [§3] The first inference rule for load appears to use Γ ⊢ f:FunctionRef as both premise and conclusion; please correct the rule and provide a proper typing environment/syntax for the rest of the judgments.
  2. [§5.1] The sentence “All fail before code generation with a diagnostic message matching the expected error” should state how “expected” was determined and whether the message matching was automated or manual.
  3. [§5.2] Please clarify the relationship between the 11 workloads used for the source-size comparison and the five changes used for the diff comparison: are the five changes drawn from those 11 workloads, and how were the hand-written C/libbpf baselines selected?
  4. [§5.3] Please add a breakdown of the 43 repository examples by program type. The text reports 27 single-program XDP objects separately but does not state how the remaining examples are distributed across TC, kprobe, tracepoint, struct_ops, etc.
  5. [§4 / Availability] The paper mentions the compiler is written in OCaml with dune but provides no artifact URL or availability statement. For a systems/PL paper whose claims are empirical, an artifact link is important for reproducibility.

Circularity Check

0 steps flagged

No circularity: cross-boundary claims are checked against external C/libbpf behavior; unverified 28/31 counterfactual is an evidence gap, not circularity.

full rationale

KernelScript's derivation chain is not circular. The central claim is empirical and comparative: generated eBPF objects are checked by a type system, and the type errors are compared against the behavior of standard C/libbpf. No parameter is fitted to the evaluation data and then re-reported as a prediction; no uniqueness theorem or ansatz is imported from prior work. The type rules in §3, e.g., Γ⊢load(f):ProgramHandle and Γ⊢attach(h,t,fl):u32 with h:ProgramHandle, are design definitions that make attach-before-load a type error by construction. But this is the intended semantics of a DSL, not a circular derivation: the paper does not claim to have inferred these rules from the rejection data, and the rules are independently motivated by typestate/linear-type literature. The evaluation (§5.1) tests the compiler against a rejection suite and separately verifies the counterfactual for three prior-work cases by building/loading them with C/libbpf and observing runtime misbehavior; that counterfactual is external evidence. The self-citations ([6], [25]–[28]) are related-work/background and do not carry the argument. The paper itself states limitations that are evidence gaps rather than circularity: only 3 of 31 rejected programs are checked against C/libbpf, lifecycle checking covers only load ≺ {attach, detach}, and §5.3 reports a libbpf/bpftool version skew requiring a one-line fix in two examples. These reduce the strength of the universal phrasing in the abstract but do not make any claim equivalent to its own input. Hence no circular step and score 0.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 1 invented entities

No numbers are fitted to data anywhere: the evaluation reports measurements (LOC, Gbps, ns), not fitted parameters. The load-bearing premises are all domain assumptions: representativeness of the self-selected 43-workload corpus; correspondence between the §3 typing rules and real libbpf/bpftool behavior (partially verified for 3 cases); correctness of an unshipped, unverified OCaml compiler; and the claim that the raw-header escape hatch does not erode the guarantees. One new abstraction (FunctionRef/ProgramHandle) is introduced with evidence only internal to the paper.

axioms (4)
  • domain assumption The 43-workload corpus and the 5 constructed changes are representative of real eBPF applications.
    Generality of the size/diff/compatibility claims rests on corpus representativeness; §5.2-5.3. The corpus is self-selected and not shipped, so representativeness is unverifiable.
  • domain assumption The typing rules of §3 match the real failure modes of libbpf/bpftool at load and runtime.
    The rejection-suite claim depends on this correspondence; only the 3 prior-work cases are verified against the C/libbpf counterfactual (§5.1). If the rules rejected things C/libbpf would never load, the benefit claim would not hold.
  • domain assumption The OCaml compiler (nine modules, dune) correctly implements the stated typing rules and codegen.
    No formal verification, no shipped artifact, and no testing details for the compiler itself; §4 describes structure, not verification. Compiler bugs would invalidate both the rejection and compatibility results.
  • ad hoc to paper The include/extern fallback to raw headers does not undermine the cross-boundary guarantee in tested workloads.
    §4: 'For fast-moving interfaces, include and extern declarations provide a fallback to raw headers.' Any program that uses the fallback exits the typed world the paper's guarantees describe; the paper does not state how the fallback interacts with the 43-workload results.
invented entities (1)
  • FunctionRef vs ProgramHandle type split no independent evidence
    purpose: Makes load-before-attach a compile-time type error instead of a runtime failure: only load() converts a FunctionRef into a ProgramHandle, and attach/detach accept only ProgramHandle (§3).
    The one genuinely new abstraction in the design. Its value is demonstrated only through the paper's own 31-program rejection suite; there is no external formalization, machine-checked proof, or independent benchmark of the typing construct itself.

pith-pipeline@v1.3.0-alltime-deepseek · 7381 in / 21971 out tokens · 200126 ms · 2026-07-31T23:35:28.318445+00:00 · methodology

0 comments
read the original abstract

eBPF lets developers extend Linux with custom packet processing, tracing, and scheduling logic, and a verifier proves before execution that the code will not crash the kernel. The programming model, however, is fragmented: a single application spans kernel code, a userspace loader, and shared maps, yet the relationships among these pieces go unchecked. E.g. A map or event type defined differently on each side silently corrupts shared state. We observe that these cross-boundary relationships duplicate information that a type system can unify. We present KernelScript, a DSL that types maps, program handles, and execution domains in one source, then compiles to standard C through the original toolchain. We evaluate KernelScript on 43 eBPF workloads covering XDP, TC, kprobe, tracepoint, and struct_ops. KernelScript rejects cross-boundary bugs at compile time that standard C/libbpf still builds and loads, a unified source shrinks the diffs for cross-boundary changes by 5x, and generated code remains compatible with the existing toolchain.

Figures

Figures reproduced from arXiv: 2607.23900 by Cong Wang, Siyuan Sun, Yusheng Zheng.

Figure 1
Figure 1. Figure 1: Compilation pipeline. The compiler checks cross￾boundary relationships and emits C, and the existing clang/bpftool/libbpf toolchain produces the final binary. To meet these goals, the compiler parses KernelScript source, resolves imports and includes, builds symbol tables, type-checks across programs, checks safety constraints, builds an IR, and emits C ( [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Changed LOC for the same five changes. Ker￾nelScript stays in a single typed source, while C/libbpf re￾quires multi-file coordination (median 6 vs. 30 LOC, and KernelScript needs no manual kernel/userspace/header sync on any change). 6 Related Work Existing work on eBPF development falls into three cate￾gories. Specialized DSLs target particular use cases, includ￾ing bpftrace for tracing [2], BPFBox and Ac… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

30 extracted references · 3 linked inside Pith

  1. [1]

    Aya contributors. 2026. Aya: Rust eBPF library.https://github.com/ aya-rs/aya

    2026

  2. [2]

    bpftrace developers. 2026. bpftrace: High-level tracing language for Linux eBPF.https://github.com/bpftrace/bpftrace

    2026

  3. [3]

    Cilium contributors. 2026. cilium/ebpf: eBPF library for Go.https: //github.com/cilium/ebpf

    2026

  4. [4]

    Vishnu Asutosh Dasu, Monika Santra, Md Rafi Ur Rashid, Ashish Kumar, Saeid Tizpaz-Niari, and Gang Tan. 2026. Heimdall: Formally Verified Automated Migration of Legacy eBPF Programs to Rust. arXiv preprint arXiv:2605.25411

    Pith/arXiv arXiv 2026

  5. [5]

    Robert DeLine and Manuel Fähndrich. 2001. Enforcing High-Level Protocols in Low-Level Software. InProceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). 59–69. doi:10.1145/378795.378811

    arXiv 2001

  6. [6]

    eunomia-bpf developers. 2024. eunomia-bpf: A Dynamic Loading Framework for eBPF.https://github.com/eunomia-bpf/eunomia-bpf

    2024

  7. [7]

    William Findlay, Anil Somayaji, and David Barrera. 2020. BPFBox: Simple Precise Process Confinement with eBPF. InProceedings of the 2020 ACM SIGSAC Conference on Cloud Computing Security Workshop (CCSW). 91–103. doi:10.1145/3411495.3421358

    arXiv 2020

  8. [8]

    Yoann Ghigoff, Julien Sopena, Kahina Lazri, Antoine Blin, and Gilles Muller. 2021. BMC: Accelerating Memcached using Safe In-kernel Caching and Pre-stack Processing. InProceedings of the 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI). 487–501.https://www.usenix.org/conference/nsdi21/presentation/ ghigoff

    2021

  9. [9]

    Toke Høiland-Jørgensen, Jesper Dangaard Brouer, Daniel Borkmann, John Fastabend, Tom Herbert, David Ahern, and David Miller. 2018. The eXpress Data Path: Fast Programmable Packet Processing in the Operating System Kernel. InProceedings of the 14th International Conference on Emerging Networking Experiments and Technologies (CoNEXT). 54–66

    2018

  10. [10]

    Vasconcelos, and Makoto Kubo

    Kohei Honda, Vasco T. Vasconcelos, and Makoto Kubo. 1998. Language Primitives and Type Discipline for Structured Communication-Based Programming. InProgramming Languages and Systems (ESOP). 122–

    1998

  11. [11]

    Jack Tigar Humphries, Neel Natu, Ashwin Chaugule, Ofir Weisse, Barret Rhoden, Josh Don, Luigi Rizzo, Oleg Noskov, Paul Turner, and Christos Kozyrakis. 2021. ghOSt: Fast & Flexible User-Space Delega- tion of Linux Scheduling. InProceedings of the 28th ACM Symposium on Operating Systems Principles (SOSP). 588–604. doi:10.1145/3477132. 3483542

    doi:10.1145/3477132 2021

  12. [12]

    iovisor/bcc developers. 2026. BCC: Tools for BPF-based Linux IO anal- ysis, networking, monitoring, and more.https://github.com/iovisor/ bcc

    2026

  13. [13]

    Le, Hubertus Franke, Hani Jamjoom, Tianyin Xu, and Dan Williams

    Jinghao Jia, Ruowen Qin, Milo Craun, Egor Lukiyanov, Ayush Bansal, Minh Phan, Michael V. Le, Hubertus Franke, Hani Jamjoom, Tianyin Xu, and Dan Williams. 2025. Rex: Closing the Language-Verifier Gap with Safe and Usable Kernel Extensions. In2025 USENIX Annual Techni- cal Conference (USENIX ATC 25).https://www.usenix.org/conference/ atc25/presentation/jia

    2025

  14. [14]

    KP Singh. 2020. LSM BPF: Kernel Runtime Security Instrumentation. https://docs.kernel.org/bpf/prog_lsm.html. Linux kernel 5.7+

    2020

  15. [15]

    libbpf developers. 2026. libbpf: a BPF CO-RE userspace library.https: //github.com/libbpf/libbpf

    2026

  16. [16]

    Luke Nelson, James Bornholt, Ronghui Gu, Andrew Baumann, Emina Torlak, and Xi Wang. 2019. Scaling Symbolic Evaluation for Automated Verification of Systems Code with Serval. InProceedings of the 27th ACM Symposium on Operating Systems Principles (SOSP). 225–242. doi:10.1145/3341301.3359641

    arXiv 2019

  17. [17]

    P4 Language Consortium. 2024. P4c-eBPF: P4 Compiler Backend for eBPF.https://github.com/p4lang/p4c/tree/main/backends/ebpf. 5

    2024

  18. [18]

    Swarn Priya, Frédéric Besson, Connor Sughrue, Tim Steen- voorden, Jamie Fulford, Freek Verbeek, and Binoy Ravin- dran. 2025. BeePL: Correct-by-Compilation Kernel Exten- sions. InPrinciples of Secure Compilation (PriSC @ POPL). https://popl25.sigplan.org/details/prisc-2025-PriSC-2024-1/3/BeePL- Correct-by-compilation-kernel-extensions

    2025

  19. [19]

    Shiv Kumar, S

    Animesh Singh, K. Shiv Kumar, S. VenkataKeerthy, Pragna Mamidi- paka, R. V. B. R. N. Aaseesh, Sayandeep Sen, Palanivel A. Kodeswaran, Theophilus A. Benson, Ramakrishna Upadrasta, and Praveen Tam- mana. 2026. Yaksha-Prashna: Understanding eBPF Bytecode Network Function Behavior. arXiv preprint arXiv:2602.11232

    arXiv 2026

  20. [20]

    Strom and Shaula Yemini

    Robert E. Strom and Shaula Yemini. 1986. Typestate: A Programming Language Concept for Enhancing Software Reliability.IEEE Transac- tions on Software EngineeringSE-12, 1 (1986), 157–171. doi:10.1109/ TSE.1986.6312929

    arXiv 1986

  21. [21]

    The Linux Kernel Documentation Project. 2026. eBPF Documentation. https://docs.kernel.org/bpf/

    2026

  22. [22]

    Marcos A. M. Vieira, Matheus S. Castanho, Racyus D. G. Pacífico, Elerson R. S. Santos, Eduardo P. M. Câmara Juńior, and Luiz F. M. Vieira. 2021. Fast Packet Processing with eBPF and XDP: Concepts, Code, Challenges, and Applications.Comput. Surveys53, 1 (2021), 1–36. doi:10.1145/3371038

    doi:10.1145/3371038 2021

  23. [23]

    Philip Wadler. 1990. Linear Types Can Change the World! InPro- gramming Concepts and Methods, M. Broy and C. Jones (Eds.). North- Holland.https://oa.mg/work/2912106379

    arXiv 1990

  24. [24]

    Xi Wang, David Lazar, Nickolai Zeldovich, Adam Chlipala, and Zachary Tatlock. 2014. Jitk: A Trustworthy In-Kernel Inter- preter Infrastructure. InProceedings of the 11th USENIX Sympo- sium on Operating Systems Design and Implementation (OSDI). 33– 47.https://www.usenix.org/conference/osdi14/technical-sessions/ presentation/wang_xi

    2014

  25. [25]

    Yusheng Zheng, Tianyuan Wu, Quanzhi Fu, Tong Yu, Wenan Mao, Tao Ma, Dan Williams, Wei Wang, and Andi Quinn. 2026. ActPlane: Programmable OS-Level Policy Enforcement for Agent Harnesses. arXiv preprint arXiv:2606.25189

    Pith/arXiv arXiv 2026

  26. [26]

    Yusheng Zheng, Tong Yu, Yiwei Yang, Yanpeng Hu, Xiaozheng Lai, Dan Williams, and Andi Quinn. 2025. Extending Applications Safely and Efficiently. In19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25).https://www.usenix.org/ conference/osdi25/presentation/zheng-yusheng

    2025

  27. [27]

    Yusheng Zheng, Tong Yu, Yiwei Yang, Minghui Jiang, Xiangyu Gao, Jianchang Su, Yanpeng Hu, Wenan Mao, Wei Zhang, Dan Williams, and Andi Quinn. 2025. gpu_ext: Extensible OS Policies for GPUs via eBPF. arXiv preprint arXiv:2512.12615

    arXiv 2025

  28. [28]

    Yusheng Zheng, Tong Yu, Yiwei Yang, and Andrew Quinn. 2024. Wasm- bpf: Streamlining eBPF Deployment in Cloud Environments with WebAssembly. arXiv preprint arXiv:2408.04856

    Pith/arXiv arXiv 2024

  29. [29]

    Tal Zussman, Ioannis Zarkadas, Jeremy Carin, Andrew Cheng, Hu- bertus Franke, Jonas Pfefferle, and Asaf Cidon. 2025. cache_ext: Customizing the Page Cache with eBPF. InProceedings of the 30th ACM Symposium on Operating Systems Principles (SOSP). 462–478. doi:10.1145/3731569.3764820 6

    arXiv 2025

  30. [138]

    doi:10.1007/BFb0053567

    doi:10.1007/bfb0053567