Skip to content

iter: add None/NULL variant for attach IterOpts#1352

Merged
d-e-s-o merged 1 commit intolibbpf:masterfrom
ver-nyan:iter_attach_opts-null
Mar 2, 2026
Merged

iter: add None/NULL variant for attach IterOpts#1352
d-e-s-o merged 1 commit intolibbpf:masterfrom
ver-nyan:iter_attach_opts-null

Conversation

@ver-nyan
Copy link
Copy Markdown
Contributor

Add IterOpts::None variant for attaching with no bpf_iter_link_info specified to bpf_program__attach_iter.

Also removes the From<IterOpts> for bpf_iter_link_info trait since the None variant does not map to any of its union members.

Closes #1348

Currently set as draft since there's a compiler false positive unused_assignments, same as rust-lang/rust#150656. I'll try to satisfy it after I get some confirmation in the Rust issue.

@ver-nyan
Copy link
Copy Markdown
Contributor Author

ver-nyan commented Mar 2, 2026

I still have mixed feelings about IterOpts::None vs changing signature to Option<IterOpts>, but ill defer to whatever you think is best.

Also since From<IterOpts> trait is a public API, should we still remove it?
If keeping it, i can add a rustdoc note about the unreachable on IterOpts::None variant in that case.

Copy link
Copy Markdown
Collaborator

@d-e-s-o d-e-s-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still have mixed feelings about IterOpts::None vs changing signature to Option<IterOpts>, but ill defer to whatever you think is best.

I don't think a with_opts method should have optional opts. It makes no sense to me. That, and I don't want to break backwards compat for a minor change like this. If you can come up with a reasonable alternative design then we can go with that.

Also since From<IterOpts> trait is a public API, should we still remove it? If keeping it, i can add a rustdoc note about the unreachable on IterOpts::None variant in that case.

From my perspective it's an implementation detail that we needed such a conversion and added it via a public facing trait impl. Yes, removal is strictly speaking breaking, but I seriously doubt anybody will depend on the existence of this impl: no other public function even accepts a bpf_iter_link_info.

Comment thread libbpf-rs/src/program.rs Outdated
let mut linkinfo = libbpf_sys::bpf_iter_link_info::from(opts);
let mut linkinfo = match opts {
IterOpts::None => None,
IterOpts::Map(map_opts) => Some(libbpf_sys::bpf_iter_link_info {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please make sure to destruct the inner objects exhaustively, as was the case in the From impl? Same below.

I'd also prefer we don't name bindgen anonymous types ala xxx_bindgen_ty_1, but we can keep that if need be.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They should be destructed now, and the bindgen_ty aren't directly referenced now. 👍

Add `IterOpts::None` variant for attaching with no `bpf_iter_link_info`
to `bpf_program__attach_iter()`.

Also removes the `From<IterOpts> for bpf_iter_link_info` trait since the
`None` variant does not map to any of its union members.

Closes libbpf#1348
@ver-nyan ver-nyan force-pushed the iter_attach_opts-null branch from eff21e4 to 57003a4 Compare March 2, 2026 22:58
Copy link
Copy Markdown
Collaborator

@d-e-s-o d-e-s-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me now, thanks!

@d-e-s-o d-e-s-o merged commit 92f3204 into libbpf:master Mar 2, 2026
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

attach_iter() API with no options specified

2 participants