On 2026-07-08 11:14 +0200, Christian Brauner wrote: > On 2026-07-07 15:44 -0700, Farid Zakaria wrote: > > 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 not call this polished and it also lacks any tests... I've not > given the locking much thought and maybe there's easy wins on the table > I haven't been considering. > > > 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. > > This isn't my first bpf ride in both kernel and userspace. > > > What does "take it from here" mean in practicality? > > Bring it over the finish line so I can merge it into my tree. :) > If the bpf people have no comments or worries than we're done. If they > want changes I'd appreciate if you could make them and slap you > Co-developed-by onto the whole thing as necessary. > > Also, please ensure that this works for all the cases you're > considering.
I have another cleanup series for binfmt_misc btw. That code is quite old. There might be a few additional series coming out of this work that we base the bpf bits on.
