Introduce AsRawLibbpf trait #581
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
libbpf-rs aims to be a convenient but thin wrapper around libbpf functionality. However, not all functionality provided by libbpf is exposed through its API. This can quickly become a blocker if, say, some getter is not hooked up, but the returned value required to perform an operation. In the spirit of being a thin wrapper, it makes sense for us to provide access to the underlying libbpf objects. When nothing else is available, these can be used directly in conjunction with libbpf-sys to, effectively, write Rust-syntax C code. So far we have provided very ad-hoc accessor methods for retrieving pointers to the underlying libbpf objects. With this change we formalize this approach some more, by introducing the AsRawLibbpf trait and implementing it for major libbpf-rs types. Using a trait is not the only possible way. We could also continue on the path we were on earlier where relevant types had custom named accessors without a common trait (e.g., Map::as_libbpf_bpf_map_ptr). The benefits a trait brings to the table is that it unifies naming and makes it reasonably easy to get an overview of types that have libbpf counterparts. The risk is that we may have to adjust the trait signature in one way or another if a newly added type has different constraints (e.g., if a libbpf-rs object has a potentially-NULL libbpf object). Signed-off-by: Daniel Müller <[email protected]>
danielocfb
force-pushed
the
topic/as-libbpf-obj
branch
3 times, most recently
from
017e0d4
to
e90f404
Compare
|
Maybe "AsRawLibbpf"? "AsLibbpfObject" reads amibuous - those words have been used a lot in libbpf-rs as well |
Fine with me, will adjust. Thanks for the feedback. |
danielocfb
force-pushed
the
topic/as-libbpf-obj
branch
from
e90f404
to
5014756
Compare
danielocfb
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
libbpf-rsaims to be a convenient but thin wrapper aroundlibbpffunctionality. Not all functionality provided oflibbpfis exposed through its API. This can quickly become a blocker if, say, some getter is not hooked up, but the value required to perform an operation. In the spirit of being a thin wrapper, it makes sense for us to provide access to the underlyinglibbpfobjects. When nothing else is available, these can be used directly in conjunction withlibbpf-systo, effectively, write Rust-syntax C code.So far we have provided very ad-hoc accessor methods for retrieving pointers to the underlying
libbpfobjects. With this change we formalize this approach some more, by introducing theAsLibbpfObjecttrait and implementing it for majorlibbpf-rstypes.Using a trait is not the only possible way. We could also continue that path we were on earlier where relevant types had custom named accessors without a common trait (e.g.,
Map::as_libbpf_bpf_map_ptr). The benefits a trait brings to the table is that it unifies naming and makes it reasonably easy to get an overview of types that havelibbpfcounterparts.The risk is that we may have to adjust the trait signature in one way or another if a newly added type has different constraints (e.g., if a
libbpf-rsobject has a potentially-NULLlibbpf object).