-
Notifications
You must be signed in to change notification settings - Fork 3
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
Detect system info + available BPF features on startup #70
Conversation
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.
Looks very good overall!! Great progress so far!
We might want to look into the kernel test errors, and another thing we could do was moving all this code that is pretty much self-contained (and potentially) reusable to a top level crate similarly to how lightswitch-proto
is implemented. What do you think?
src/system_info.rs
Outdated
} | ||
|
||
fn tracefs_mount_detected() -> bool { | ||
return Path::new(PROCFS_PATH).exists(); |
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.
nice! very clean
src/system_info.rs
Outdated
|
||
fn get_trace_sched_event_id(trace_event: &str) -> Result<u32> { | ||
if !tracefs_mount_detected() { | ||
return Err(anyhow!("Failed to detect tracefs")); |
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.
We should probably have custom errors. I appreciate that currently the project abuses anyhow
, and we should change this, but let's try to make this errors into their own variants of an enum. Happy to send some hints if you need 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.
Fair point. Added a few custom errors to this file
src/system_info.rs
Outdated
err | ||
)), | ||
}, | ||
Err(_) => Err(anyhow!("Failed to read event={} id", trace_event)), |
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.
Using or_else
+ ?
might simply the code
src/system_info.rs
Outdated
} | ||
|
||
fn tracepoints_detected() -> bool { | ||
let mut tracepoints_supported = true; |
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.
style nit: not need for this variable, feel free to just return either true
or false
directly
src/system_info.rs
Outdated
return tracepoints_supported; | ||
} | ||
|
||
if unsafe { close(fd) } != 0 { |
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.
We can look into wrapping this into a type that on drop()
attempts to close this. The Drop
trait is akin to RAII in C++
- use custom errors - use drop trait - update match to map_err + ?
…to feature-detection
FWIW, the error seemed to be related to the unavailability of the
That sounds reasonable. Maybe |
Signed-off-by: Okwudili Pat-Nebe <[email protected]>
…to feature-detection
Signed-off-by: Okwudili Pat-Nebe <[email protected]>
&& self.software_perfevents_support_detected | ||
&& self.tracepoints_support_detected | ||
&& bpf_features.can_load_trivial_bpf_program | ||
&& bpf_features.has_ring_buf |
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.
We don't use ring buffers now, and when we do, most likely it will be dynamically chosen depending on the availability of ring buffers
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.
Right. I've relaxed the ringbuf requirement.
}) | ||
} | ||
|
||
pub fn has_minimal_requirements(&self) -> bool { |
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.
Nice!
@@ -0,0 +1,7 @@ | |||
#ifdef __TARGET_ARCH_x86 | |||
#include "vmlinux_x86.h" |
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.
Given how large vmlinux is and that we might want to keep just on copy, what do you think of using either symlinks or including the file from the other crate directly here?
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.
Done. Changed this to a symlink
Makes sense!
What about |
} | ||
} | ||
|
||
// TODO: How can we make this an integration/system test? |
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.
It's totally fine to leave it here. Personally I don't think the difference between purely no-IO unittests and integration tests matters that much, unless we need to test a binary, in that case we should use the tool level folder instead. The standard in the Rust world is to add integration tests in test/
so here would go on lightswitch-capabilities/test
.
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.
Great job! LGTM
Context
Changes
procfs
andtracefs
are mounted.tracepoints
,perf_events
, and a few bpf helpers.Test Plan