-
Notifications
You must be signed in to change notification settings - Fork 319
refactor: allow eBPF crates to compile on host architecture #1229
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -133,6 +133,16 @@ pub fn check_bounds_signed(value: i64, lower: i64, upper: i64) -> bool { | |
} | ||
} | ||
|
||
#[macro_export] | ||
macro_rules! main_stub { | ||
() => { | ||
#[cfg(not(target_arch = "bpf"))] | ||
fn main() { | ||
panic!(r#"eBPF kernels are not designed to be executed in user-space. This main function is only a placeholder to allow the code to compile on the host system (i.e. on any system that is not `target_arch = "bpf"`). This works in tandem with the `no_main` attribute which is only applied when compiling for `target_arch = "bpf"`."#) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See #1229 (comment) This is not a meaningful message like I asked. This is basically just saying "we need this because no_main only on bpf" but doesn't explain why we can't keep no_main in place when targeting not-bpf. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you please write out message that you'd like to see? 🙏 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd love to, but I actually don't know the reason. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The crate doesn't compile without a main function (for the host architecture). I guess the reasons is "binaries need an entrypoint"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're still not answering the question, or am I missing something? Why can't There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't how else to say it, the code doesn't compile without a
If I add the
Based on the above, it appears to me that "Binaries don't compile without a main function and therefore we need a stub when compiling for the host architecture" is a pretty solid explanation but I am open to other suggestions if you have a specific wording in mind. |
||
} | ||
}; | ||
} | ||
|
||
#[inline] | ||
fn insert<K, V>( | ||
def: *mut bindings::bpf_map_def, | ||
|
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 am open to changing this to something else other than a macro by example if we can come up with something elegant.
AFAIK, eBPF progams can have multiple entry points so we cannot really attach it to another proc-macro, at least not in the general case.
Leaning onto the idea from @dave-tucker, we could define a
aya_ebpf::main
macro that people can add to their entrypoint:It is not very elegant though because the handler itself has nothing to do with the generated
main
stub, i.e. putting the attribute on any other function would also work.Given that we already use nightly, we could try and build something on top of
#![feature(custom_inner_attributes)]
?Using that, we could perhaps lump the
no_std
,no_main
andmain
stub together so that users only have to define one macro, like:#![aya_ebpf::program]