On Tue, May 24, 2022 at 03:30:31PM -0700, Andrii Nakryiko wrote:
> On Fri, May 20, 2022 at 1:51 PM Martin KaFai Lau <kafai@xxxxxx> wrote:
> >
> > On Tue, May 10, 2022 at 01:59:19PM -0700, Kui-Feng Lee wrote:
> > [ ... ]
> > > --- a/include/uapi/linux/bpf.h
> > > +++ b/include/uapi/linux/bpf.h
> > > @@ -1013,6 +1013,7 @@ enum bpf_link_type {
> > > BPF_LINK_TYPE_XDP = 6,
> > > BPF_LINK_TYPE_PERF_EVENT = 7,
> > > BPF_LINK_TYPE_KPROBE_MULTI = 8,
> > > + BPF_LINK_TYPE_STRUCT_OPS = 9,
> > Sorry for the late question. I just noticed it while looking at the
> > cgroup-lsm set.
> >
> > Does BPF_LINK_TYPE_STRUCT_OPS need to be in the uapi?
> > The current links of the struct_ops progs should not be
> > visible to the user space.
> >
>
> bpf_link_init() expects link_type to be specified, so we have to
> provide some value. We probably could have specified
> BPF_LINK_TYPE_UNSPEC, but that seems wrong. But right now those links
> are not going to be visible outside as they don't get their ID
> allocated (no bpf_link_settle() call), so we just basically have a
> reserved enum for future STRUCT_OPS link, if we ever add it
> explicitly.
I was also thinking BPF_LINK_TYPE_UNSPEC could have been used
since the user space cannot get a hold of those kernel internal
links which is one link for one struct_ops's prog.
I was asking because the current bpf_link libbpf api for struct_ops has
already caused confusion as if there was a kernel supported bpf_link for
the struct_ops map (kernel supported bpf_link is where we want to do
in the future). The new BPF_LINK_TYPE_STRUCT_OPS in the uapi here may
have added some more confusion on this.
I don't mind to keep it here as a enum holder. just want to double
check it is not useful to the userspace now and can be reused later, and
probably need something else for the current struct_ops's prog link.
