On Fri, Sep 03, 2021 at 06:09:46PM -0700, Cong Wang wrote: > On Wed, Sep 1, 2021 at 10:45 AM Martin KaFai Lau <kafai@xxxxxx> wrote: > > _if_ it is using as a qdisc object/interface, > > the patch "looks" easier because it obscures some of the ops/interface > > from the bpf user. The user will eventually ask for more flexibility > > and then an on-par interface as the kernel's qdisc. If there are some > > common 'ops', the common bpf code can be shared as a library in userspace > > or there is also kfunc call to call into the kernel implementation. > > For existing kernel qdisc author, it will be easier to use the same > > interface also. > > Thanks for showing the advantages of a kernel module. And no, we > are not writing kernel modules in eBPF. The line is very blurry between a bpf_prog and kernel module, especially with the advancement of bpf, btf, and CO-RE. Both bpf_prog.o (struct_ops or not) and some_native_kern_mod.ko are attaching to some kernel hooks to be called. If writing bpf and attaching it to a hook does not work for you, bpf does not fit your case. > And kfunc call really sucks, it does not even guarantee a stable ABI, it > is a serious mistake you made for eBPF. Not ture. It depends on what is allowed to be called by bpf. Needless to say I cannot agree with the "sucks" description. This kind of dismissive discussion is worse than unproductive and not the best way to use the mailing list time.
