On Thu, Jan 23, 2025 at 11:15:21AM +0100, Gerd Bayer wrote: > On Thu, 2025-01-23 at 15:30 +0800, Dust Li wrote: > > On 2025-01-23 09:59:39, D. Wythe wrote: > > > The introduction of IPPROTO_SMC enables eBPF programs to determine > > > whether to use SMC based on the context of socket creation, such as > > > network namespaces, PID and comm name, etc. > > > > > > > I'm still not completely satisfied with the name smc_ops. Since this > > will be the API for our users, we need to be carefull on the name. > > If I may jump in with a suggestion here: > On my first glance, I'd expect SMC_OPS to offer OPS as a general API. > The description however suggest that this adds "contol points" or hooks > in the SMC code, that eBPF programs can use to tweak the protocol's > behavior. Exclusively eBPF programs, it seems. > > So how about naming this SMC_EBPF_HOOKS or SMC_EBPF_SUPPORT? > > Just my 2ct, > Gerd Hi all, Thanks for all the suggestion.It seems that the naming of this ops has indeed sparked some controversy. However, I still oppose explicitly linking the name to BPF. As I mentioned earlier, this ops is not strongly tied to BPF implementations, kernel modules can also implement them. I used ChatGPT to generate some potential names, including: smc_ops / smc_hook / smc_aug / smc_ext / smc_alert / smc_support Perhaps these can be used as references. However, in any case, these changes need to be acked by the SMC maintainer, but for what I can tell, the maintainer of SMC is currently on leave, so this discussion may still take some time. Best wishes, D. Wythe > > > > > It seems like you're aiming to define a common set of operations, but > > the implementation appears to be intertwined with BPF. If this is > > intended to be a common interface, and if we are using another operation, > > there shouldn’t be a need to hold a BPF reference. > > > > As your 'help' sugguest, What about smc_hook ? > > > > Best regards, > > Dust > > > >
