-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpf: Add bpf_strncmp
helper
#871
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for aya-rs-docs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
f937b7b
to
c8f5da1
Compare
let dst = unsafe { ptr.as_mut() }; | ||
let TestResult(dst_res) = dst.ok_or(-1)?; | ||
|
||
let cmp_res = bpf_strncmp(str_bytes, c"fff"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alessandrod Are you fine with using CStr literals here? I had a bit of dilemma, since their stabilization goes slow. The other alternative could be using byte literals and forcing people to null terminate them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the literal is fine, but both arguments should be &CStr?
bpf/aya-bpf/src/helpers.rs
Outdated
/// } | ||
/// ``` | ||
#[inline] | ||
pub fn bpf_strncmp(s1: &[u8], s2: &CStr) -> Ordering { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the API why one is a slice and the other is &CStr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the most common way of using bpf_strncmp
I've seen (and I'm doing in my projects 😛 ) is comparing a string we got from bpf_probe_read_user_str_bytes
(which returns a byte slice) with some literal written in the program (where the CStr literal is very handy).
But yeah, I get your point about consistency. Since our whole bpf_probe_read_*_bytes
API returns byte slices, I see two solutions:
- We just use byte slices. And tell people to use byte literals - I'm mostly convinced to that so far.
- We make everything return CStr - but nah, we would need to care about null termination checks and so.
So let's maybe make both &[u8]
@vadorovsky, this pull request is now in conflict and requires a rebase. |
The `bpf_strncmp` helper allows for better string comparison in eBPF programs. Kernel patchset: https://lore.kernel.org/bpf/[email protected]/
@vadorovsky, this pull request is now in conflict and requires a rebase. |
The
bpf_strncmp
helper allows for better string comparison in eBPF programs.Kernel patchset:
https://lore.kernel.org/bpf/[email protected]/