Re: num_args branch

G'day Filipe,

I hope you are doing well.

Now that the samples work and I can verify them on RISC-V and ARM, I
thought adding static analysis would help.

Static analysis should help us a bit faster.  The static analysis has
a LOT of false positives, so there is a triage system, but I think it
did find some small bugs.

Static analysis code
https://github.com/randomizedcoder/xdp2/pull/1

Bug fixes, and updated readme
https://github.com/randomizedcoder/xdp2/pull/2

I'm now working on upgrading cppfront to the latest version.

Thanks,
Dave


On Tue, Mar 17, 2026 at 8:01=E2=80=AFPM dave seddon <[email protected]=
om> wrote:
>
> G'day Tom,
>
> Sorry for the delay.
>
> The good news is that all samples work on x86, arm64 and riscv64.
> This is all Nix-ified, making it quite easy to reproduce.
> https://github.com/randomizedcoder/xdp2/blob/pr/nix-bpf-compat-samples/do=
cumentation/nix/test-summary.md
>
> Cross compilation all works via Nix
> https://github.com/randomizedcoder/xdp2/blob/pr/nix-bpf-compat-samples/do=
cumentation/nix/nix.md#cross-compilation
>
> Virtual machine-based testing is also suitable for "nightly" testing.
> It spins up qemu virtual machines and runs through a series of tests.
> https://github.com/randomizedcoder/xdp2/blob/pr/nix-bpf-compat-samples/do=
cumentation/nix/nix.md#microvm-integration-testing
>
> It took a while to get it all working and testing, and I've tried to
> break it up into a series of commits that is hopefully understandable.
> https://github.com/xdp2-dev/xdp2/pull/13
>
> I haven't tested this on Ubuntu yet, but I definitely need to do that.
> At the SCALE conference somebody had a repo for using Nix to do Ubuntu
> virtual machines, so that's probably the way to go.
>
> Thanks,
> Dave
>
>
> On Thu, Feb 26, 2026 at 8:10=E2=80=AFAM dave seddon <dave.seddon.ca@gmail=
.com> wrote:
> >
> > G'day,
> >
> > Progress on RISC-V cross-compiling is very slow.  I'm actually not sure=
 why it is so slow.  ( Maybe this could help: https://github.com/Snektron/p=
areas ? )
> >
> > I did get the little LicheePi 4A ( https://en.wiki.sipeed.com/hardware/=
en/lichee/th1520/lpi4a/1_intro.html ) out, but it's not booting for unknown=
 reasons.  :(
> >
> > Essentially, Nix compiles and links all the pieces, then it hits an err=
or, so I skip the tests, and it progresses.
> >
> > building '/nix/store/5cvh37lpbw8i6pzx78alqkyq547231n0-python3.13-cffi-1=
.17.1.drv'...
> > building '/nix/store/i5q7ifaj5dqm1xzmbls36jwcfanl6naj-nss-cacert-3.115.=
drv'...
> > building '/nix/store/af2slsbc1dy4qxdw67p9byxgk8bfizs8-python3.13-chamel=
eon-4.6.0.drv'...
> > building '/nix/store/jdm6yhfzk2m7jw1wi53qfgg8jz1wq4nf-libressl-4.1.0.dr=
v'...
> > building '/nix/store/8ksbr1fyc2m2i84v893aal0gywzbn9ni-perl5.40.0-Mozill=
a-CA-20230821.drv'...
> > building '/nix/store/9j9f40wmd97wbnxw0cxg8w8w3r1b56xs-python3.13-certif=
i-2025.07.14.drv'...
> > building '/nix/store/m5gac10c4vpxsi8kg7hr54y8lbcyr3jw-perl5.40.0-IO-Soc=
ket-SSL-2.083.drv'...
> > building '/nix/store/v9apzxsl5hjdpjn62cysg0ggjw892z9m-python3.13-click-=
8.1.8.drv'...
> > building '/nix/store/lj7mn9c9qaz8ac3qk30j8cm9crq9xz38-perl5.40.0-Net-SM=
TP-SSL-1.04.drv'...
> > building '/nix/store/mvsbz33grad5ax0niwyypnkgk3fg11dl-python3.13-defuse=
dxml-0.8.0rc2.drv'...
> > building '/nix/store/zda4nzrg7amqvrb75rp77yz2jzn9mpcw-python3.13-idna-3=
.10.drv'...
> > building '/nix/store/33a38c1yiv576pcr4bjfmd5lf0v4912r-python3.13-markup=
safe-3.0.2.drv'...
> > building '/nix/store/9wp0ay3d4sasks7gzn0mgdkp97fpvg4y-python3.13-mypy-e=
xtensions-1.1.0.drv'...
> > building '/nix/store/njw6l3q1kffri3rlc4f25avbrqf7qnnv-python3.13-psutil=
-7.0.0.drv'...
> > building '/nix/store/32c7q6zmq15x5v65jl188z36swxhxb76-python3.13-ptypro=
cess-0.7.0.drv'...
> > error: Cannot build '/nix/store/njw6l3q1kffri3rlc4f25avbrqf7qnnv-python=
3.13-psutil-7.0.0.drv'.
> >        Reason: builder failed with exit code 1.
> >        Output paths:
> >          /nix/store/pw5m4561cajw5padys0dyjd9hhc80g4j-python3.13-psutil-=
7.0.0
> >          /nix/store/r2w0k92mwnpf41wgbbaj0sj2kxzwznn7-python3.13-psutil-=
7.0.0-dist
> >        Last 25 log lines:
> >        >            ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ =
_ _ _ _ _ _ _ _ _
> >        >
> >        >     def net_if_stats():
> >        >         """Get NIC stats (isup, duplex, speed, mtu)."""
> >        >         duplex_map =3D {
> >        >             cext.DUPLEX_FULL: NIC_DUPLEX_FULL,
> >        >             cext.DUPLEX_HALF: NIC_DUPLEX_HALF,
> >        >             cext.DUPLEX_UNKNOWN: NIC_DUPLEX_UNKNOWN,
> >        >         }
> >        >         names =3D net_io_counters().keys()
> >        >         ret =3D {}
> >        >         for name in names:
> >        >             try:
> >        >                 mtu =3D cext_posix.net_if_mtu(name)
> >        >                 flags =3D cext_posix.net_if_flags(name)
> >        > >               duplex, speed =3D cext.net_if_duplex_speed(nam=
e)
> >        >                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        > E               OSError: [Errno 25] Inappropriate ioctl for de=
vice (originated from ioctl(SIOCETHTOOL))
> >        >
> >        > /nix/store/pw5m4561cajw5padys0dyjd9hhc80g4j-python3.13-psutil-=
7.0.0/lib/python3.13/site-packages/psutil/_pslinux.py:1055: OSError
> >
> >
> > Probably the best way forward would be to get one of these for ~$130
> > https://www.amazon.com/youyeetoo-Banana-BPI-F3-Acrylic-Developer/dp/B0D=
FPZ8B6G/?th=3D1
> >
> > Regards,
> > Dave
> >
> > On Fri, Feb 20, 2026 at 11:41=E2=80=AFAM dave seddon <dave.seddon.ca@gm=
ail.com> wrote:
> >>
> >> Oh my goodness compiling RISC-V is slow!  Actually, cross compiling is
> >> ok, it's the other steps that need to run by the emulation that is
> >> slow.
> >>
> >> I actually have a little RISC-V SoC, so I'm away this weekend, but
> >> early next week I can dig that out and try to get it going.
> >>
> >> On Wed, Feb 18, 2026 at 10:02=E2=80=AFAM dave seddon <dave.seddon.ca@g=
mail.com> wrote:
> >> >
> >> > G'day,
> >> >
> >> > I hope you are doing well.
> >> >
> >> > I have a basic virtual machine based test that:
> >> > 1. Spins up the VM
> >> > 2. Verifies boot
> >> > 3. VM itself attaches the ebpf code to an interface.  This obviously
> >> > causes the ebpf verifier to run.
> >> > 4. Script then verifies the attachment to the interface
> >> > 5. Shuts down
> >> >
> >> > Hopefully this is enough for the initial implementation.  Obviously,
> >> > it would be nice to actually send some packets to see that the ebpf
> >> > code <does the thing>, but that can come later.
> >> >
> >> > I've done this for x86, because this was the quickest thing to get
> >> > working.  I'll now start on adding more architectures.  I assume you
> >> > what riscv 32 and 64.
> >> >
> >> > How long will it take?  "Prediction is very difficult =E2=80=94 espe=
cially
> >> > about the future".  Maybe a few more days?  I could be very wrong.
> >> >
> >> > Thanks,
> >> > Dave
> >> >
> >> > On Mon, Feb 16, 2026 at 5:03=E2=80=AFPM dave seddon <dave.seddon.ca@=
gmail.com> wrote:
> >> > >
> >> > > G'day,
> >> > >
> >> > > I just got all the samples working with the 5 args.  Awesome!
> >> > >
> >> > > Changing common_parser.template.c was required to get parser_tmpl =
-O working
> >> > >
> >> > > --------------------
> >> > > [das@l:~/Downloads/xdp2]$ git diff src/templates/xdp2/common_parse=
r.template.c
> >> > > diff --git a/src/templates/xdp2/common_parser.template.c
> >> > > b/src/templates/xdp2/common_parser.template.c
> >> > > index 82792e6..91f5bb3 100644
> >> > > --- a/src/templates/xdp2/common_parser.template.c
> >> > > +++ b/src/templates/xdp2/common_parser.template.c
> >> > > @@ -50,7 +50,7 @@ static inline __unused() int
> >> > >         <!--(end)-->
> >> > >
> >> > >         ret =3D __@!parser_name!@_@!root_name!@_xdp2_parse(
> >> > > -                       parser, hdr, len, metadata, frame, 0, ctrl=
, flags);
> >> > > +                       parser, hdr, len, metadata, &frame, 0, ctr=
l, flags);
> >> > >
> >> > >         ctrl->var.ret_code =3D ret;
> >> > >
> >> > >
> >> > > [das@l:~/Downloads/xdp2]$
> >> > > --------------------
> >> > >
> >> > > Starting to work on the samples/xdp/ next
> >> > >
> >> > > Thanks!
> >> > > Dave
> >> > >
> >> > > On Sun, Feb 15, 2026 at 8:14=E2=80=AFPM dave seddon <dave.seddon.c=
[email protected]> wrote:
> >> > > >
> >> > > > Awesome.  Thanks for the update.  I'll try to take a look tomorr=
ow.
> >> > > >
> >> > > >
> >> > > > On Sun, Feb 15, 2026 at 5:21=E2=80=AFPM Tom Herbert <tom@herbert=
land.com> wrote:
> >> > > > >
> >> > > > > HI,
> >> > > > >
> >> > > > > I added a num_args branch in xdp2-dev/xdp2 that has the propos=
ed fix for the handlers and metadata extraction functions exceeding the fiv=
e argument limit of eBPF. Haven't tested much yet. Please give it a try if =
you can.
> >> > > > >
> >> > > > > Tom
> >> > > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Regards,
> >> > > > Dave Seddon
> >> > > > +1 415 857 5102
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Regards,
> >> > > Dave Seddon
> >> > > +1 415 857 5102
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Dave Seddon
> >> > +1 415 857 5102
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Dave Seddon
> >> +1 415 857 5102
> >
> >
> >
> > --
> > Regards,
> > Dave Seddon
> > +1 415 857 5102
>
>
>
> --
> Regards,
> Dave Seddon
> +1 415 857 5102



--=20
Regards,
Dave Seddon
+1 415 857 5102