On Tue Jul 7, 2026 at 12:45 PM PDT, Christian Brauner wrote: > On 2026-07-07 13:34 +0200, Christian Brauner wrote: >> On 2026-07-06 09:47:53-07:00, Farid Zakaria wrote: >> > On Mon, Jul 6, 2026 at 9:01 AM Christian Brauner <[email protected]> >> > wrote: >> > >> > > Ignoring the blatant bpf abuse here I think this is quite workable. So >> > > this can be turned into an actual design and patch imho... >> > >> > Glad to see you think this proposal is in the right direction. >> > Just for my edification, when you say "balatant bpf abuse", you mean >> > how it abuses the socket bpf type? >> > If so, do you have any guidance on a new type or should I just take a >> > stab at it. > > I drafted a POC for you that should be closer to how this should look > like with the bpf people in Cc. I'll let you lead from now on. I just > wanted to help you out and illustrate a more viable direction. Might be > that the bpf people want it done differentely. Let's see.
Cool. I just saw the POC. (I'm trying out aerc to view the patch series. I will also try b4, I've never set it up before) I will rework my qemu demo to use the struct_ops and go through my own testing to see it work. That looks very similar to what I was researching with an LLM. I was just going over the idea of struct_ops bpf (a new concept to me) and using traditional bpftool load, a new bpf program type and kfuncs. You put out a surprising amount of polished code -- thank you. I would have had to lean on an LLM (heavily) and from the patches I've put up so far they still have quite the gap to cover in terms of polish. What does "take it from here" mean in practicality? I will test & validate the changes and just wait for comments. If there are none and it works....then I guess it's done ;P
