Re: num_args branch
dave seddon <[email protected]> Fri, 20 Mar 2026 14:23:49 -0700
| Newsgroups | dev.linux.lists.xdp2 |
|---|---|
| Message-ID | <CANypexT5fLK_kU7ExFe37RO0yiq22cobU=Wy8FE=XESciNZy=A@mail.gmail.com> |
Claude upgraded cppfront from 0.8.0 to 0.8.1. Looks good, as all the
tests are passing. The xdp2 is now applied as patches, so upgrading
next time should be a lot easier
https://github.com/randomizedcoder/xdp2/tree/upgrade/cppfront-v0.8.1/thirdp=
arty/cppfront/patches
https://github.com/xdp2-dev/xdp2/pull/14
On Thu, Mar 19, 2026 at 11:38=E2=80=AFAM dave seddon <dave.seddon.ca@gmail.=
com> wrote:
>
> 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 <dave.seddon.ca@gmail=
.com> 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/=
documentation/nix/test-summary.md
> >
> > Cross compilation all works via Nix
> > https://github.com/randomizedcoder/xdp2/blob/pr/nix-bpf-compat-samples/=
documentation/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/=
documentation/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@gma=
il.com> wrote:
> > >
> > > G'day,
> > >
> > > Progress on RISC-V cross-compiling is very slow. I'm actually not su=
re why it is so slow. ( Maybe this could help: https://github.com/Snektron=
/pareas ? )
> > >
> > > I did get the little LicheePi 4A ( https://en.wiki.sipeed.com/hardwar=
e/en/lichee/th1520/lpi4a/1_intro.html ) out, but it's not booting for unkno=
wn reasons. :(
> > >
> > > Essentially, Nix compiles and links all the pieces, then it hits an e=
rror, 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.11=
5.drv'...
> > > building '/nix/store/af2slsbc1dy4qxdw67p9byxgk8bfizs8-python3.13-cham=
eleon-4.6.0.drv'...
> > > building '/nix/store/jdm6yhfzk2m7jw1wi53qfgg8jz1wq4nf-libressl-4.1.0.=
drv'...
> > > building '/nix/store/8ksbr1fyc2m2i84v893aal0gywzbn9ni-perl5.40.0-Mozi=
lla-CA-20230821.drv'...
> > > building '/nix/store/9j9f40wmd97wbnxw0cxg8w8w3r1b56xs-python3.13-cert=
ifi-2025.07.14.drv'...
> > > building '/nix/store/m5gac10c4vpxsi8kg7hr54y8lbcyr3jw-perl5.40.0-IO-S=
ocket-SSL-2.083.drv'...
> > > building '/nix/store/v9apzxsl5hjdpjn62cysg0ggjw892z9m-python3.13-clic=
k-8.1.8.drv'...
> > > building '/nix/store/lj7mn9c9qaz8ac3qk30j8cm9crq9xz38-perl5.40.0-Net-=
SMTP-SSL-1.04.drv'...
> > > building '/nix/store/mvsbz33grad5ax0niwyypnkgk3fg11dl-python3.13-defu=
sedxml-0.8.0rc2.drv'...
> > > building '/nix/store/zda4nzrg7amqvrb75rp77yz2jzn9mpcw-python3.13-idna=
-3.10.drv'...
> > > building '/nix/store/33a38c1yiv576pcr4bjfmd5lf0v4912r-python3.13-mark=
upsafe-3.0.2.drv'...
> > > building '/nix/store/9wp0ay3d4sasks7gzn0mgdkp97fpvg4y-python3.13-mypy=
-extensions-1.1.0.drv'...
> > > building '/nix/store/njw6l3q1kffri3rlc4f25avbrqf7qnnv-python3.13-psut=
il-7.0.0.drv'...
> > > building '/nix/store/32c7q6zmq15x5v65jl188z36swxhxb76-python3.13-ptyp=
rocess-0.7.0.drv'...
> > > error: Cannot build '/nix/store/njw6l3q1kffri3rlc4f25avbrqf7qnnv-pyth=
on3.13-psutil-7.0.0.drv'.
> > > Reason: builder failed with exit code 1.
> > > Output paths:
> > > /nix/store/pw5m4561cajw5padys0dyjd9hhc80g4j-python3.13-psuti=
l-7.0.0
> > > /nix/store/r2w0k92mwnpf41wgbbaj0sj2kxzwznn7-python3.13-psuti=
l-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(n=
ame)
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^
> > > > E OSError: [Errno 25] Inappropriate ioctl for =
device (originated from ioctl(SIOCETHTOOL))
> > > >
> > > > /nix/store/pw5m4561cajw5padys0dyjd9hhc80g4j-python3.13-psuti=
l-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/B=
0DFPZ8B6G/?th=3D1
> > >
> > > Regards,
> > > Dave
> > >
> > > On Fri, Feb 20, 2026 at 11:41=E2=80=AFAM dave seddon <dave.seddon.ca@=
gmail.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=
@gmail.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 obvious=
ly
> > >> > 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. Obviousl=
y,
> > >> > it would be nice to actually send some packets to see that the ebp=
f
> > >> > 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 y=
ou
> > >> > what riscv 32 and 64.
> > >> >
> > >> > How long will it take? "Prediction is very difficult =E2=80=94 es=
pecially
> > >> > 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.c=
[email protected]> 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_tmp=
l -O working
> > >> > >
> > >> > > --------------------
> > >> > > [das@l:~/Downloads/xdp2]$ git diff src/templates/xdp2/common_par=
ser.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, ct=
rl, flags);
> > >> > > + parser, hdr, len, metadata, &frame, 0, c=
trl, 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=
[email protected]> wrote:
> > >> > > >
> > >> > > > Awesome. Thanks for the update. I'll try to take a look tomo=
rrow.
> > >> > > >
> > >> > > >
> > >> > > > On Sun, Feb 15, 2026 at 5:21=E2=80=AFPM Tom Herbert <tom@herbe=
rtland.com> wrote:
> > >> > > > >
> > >> > > > > HI,
> > >> > > > >
> > >> > > > > I added a num_args branch in xdp2-dev/xdp2 that has the prop=
osed fix for the handlers and metadata extraction functions exceeding the f=
ive argument limit of eBPF. Haven't tested much yet. Please give it a try i=
f 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
>
>
>
> --
> Regards,
> Dave Seddon
> +1 415 857 5102
--=20
Regards,
Dave Seddon
+1 415 857 5102