On 4/3/20 6:09 PM, Andrii Nakryiko wrote: > This patch series adds various observability APIs to bpf_link: > - each bpf_link now gets ID, similar to bpf_map and bpf_prog, by which > user-space can iterate over all existing bpf_links and create limited FD > from ID; > - allows to get extra object information with bpf_link general and > type-specific information; > - makes LINK_UPDATE operation allowed only for writable bpf_links and allows > to pin bpf_link as read-only file; > - implements `bpf link show` command which lists all active bpf_links in the > system; > - implements `bpf link pin` allowing to pin bpf_link by ID or from other > pinned path. > > This RFC series is missing selftests and only limited amount of manual testing > was performed. But kernel implementation is hopefully in a good shape and > won't change much (unless some big issues are identified with the current > approach). It would be great to get feedback on approach and implementation, > before I invest more time in writing tests. > The word 'ownership' was used over and over in describing the benefits of bpf_link meaning a process owns a program at a specific attach point. How does this set allow me to discover the pid of the process controlling a specific bpf_link?
