On Wed, Mar 25, 2020 at 10:38:32AM +0100, Toke Høiland-Jørgensen wrote:

quoted

As for having netlink interface for creating link only for XDP. Why
duplicating and maintaining 2 interfaces?

Totally agree; why do we need two interfaces? Let's keep the one we
already have - the netlink interface! :)

it's not about netlink vs something else.
I already explained that the ownership concept is missing.

quoted

All the other subsystems will go through bpf syscall, only XDP wants
to (also) have this through netlink. This means duplication of UAPI
for no added benefit. It's a LINK_CREATE operations, as well as
LINK_UPDATE operations. Do we need to duplicate LINK_QUERY (once its
implemented)? What if we'd like to support some other generic bpf_link
functionality, would it be ok to add it only to bpf syscall, or we
need to duplicate this in netlink as well?

You're saying that like we didn't already have the netlink API. We
essentially already have (the equivalent of) LINK_CREATE and LINK_QUERY,
this is just adding LINK_UPDATE. It's a straight-forward fix of an
existing API; essentially you're saying we should keep the old API in a
crippled state in order to promote your (proposed) new API.

It's not a fix. It papers over a giant issue with all existing attaching
apis regardless of the form (netlink, syscall, etc)
The commit 7dd68b3279f1 ("bpf: Support replacing cgroup-bpf program in MULTI mode")
is the same paper-over. It's not a fix for broken api. I regret applying it.