On Wed Jul 8, 2026 at 9:47 AM PDT, Christian Brauner wrote: > 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.
Sounds good. I just saw the patch series. My plan at the least by the weekend is to: * apply your binfmt_misc cleanup series * I will try b4 with aerc. Here is my config if anyone wants to crib it [1]. * apply your POC series for the bpf to validate * make any changes if necessary or just add selftests if it works as is [1]: https://github.com/fzakaria/nix-home/blob/aaee67c3a6d035d06a62cb75392657563de58f4a/users/fmzakari/aerc.nix
