Re: [DO_NOT_APPLY 1/2] integrate xdp-forwarder into net-vm

Yureka
2025-08-31T18:06:43Z

On 8/31/25 19:10, Alyssa Ross wrote:
> Alyssa Ross <hi@alyssa.is> writes:
>
>>> diff --git a/vm/sys/net/xdp-forwarder/default.nix
>>> b/vm/sys/net/xdp-forwarder/default.nix
>>> new file mode 100644
>>> index 0000000..75b1d66
>>> --- /dev/null
>>> +++ b/vm/sys/net/xdp-forwarder/default.nix
>>> @@ -0,0 +1,35 @@
>>> +# SPDX-License-Identifier: MIT
>>> +# SPDX-FileCopyrightText: 2025 Yureka Lilian <yureka@cyberchaos.dev>
>>> +
>>> +{ lib, runCommand, stdenv, llvmPackages, libbpf, linux, bpftools }:
>>> +
>>> +stdenv.mkDerivation {
>>> + pname = "xdp-forwarder";
>>> + version = "0";
>>> +
>>> + src = lib.fileset.toSource {
>>> + root = ./.;
>>> + fileset = lib.fileset.fileFilter
>>> + ({ hasExt, ... }: !(hasExt "nix") && !(hasExt "md")) ./.;
>>> + };
>>> +
>>> + buildInputs = [ libbpf ];
>>> + nativeBuildInputs = [ llvmPackages.clang-unwrapped bpftools ];
>>> +
>>> + buildPhase = ''
>>> + bpftool btf dump file ${linux.dev}/vmlinux format c >
>>> include/vmlinux.h
>> I guess we're still missing a vmlinux.h package in Nixpkgs? That would
>> be much cleaner.
> Actually, given discussion in #systemd:nixos.org yesterday, it sounds
> like best practice is to declare just the structs and struct members we
> use:
>
> https://nakryiko.com/posts/bpf-core-reference-guide/#defining-own-co-re-relocatable-type-definitions
>
> (Since on Spectrum we /can/ predict the kernel we'll be running on, it's
> not a huge deal, but I'd still like to follow the principle of having
> packages be portable.)

I don't really understand how avoiding vmlinux.h would make our programb
more portable.

At the same time, I am very reliant on bpf/bpf_helpers.h from libbpf,
and this requires a definition of __u64 and __u32, and I don't know
where I would get those from if not vmlinux.h (and defining them myself
feels wrong).