API change - update examples

[MarkSwanson]

Compiling the sample code found here:
https://ingraind.org/api/cargo_bpf/ (block_http/main.rs)
I get the following errors:

error[E0152]: found duplicate lang item panic_impl
--> src/test_trace.rs:8:1
|
8 | program!(0xFFFFFFFE, "GPL");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this macro invocation
|
= note: the lang item is first defined in crate std (which test_bpf depends on)

error[E0308]: mismatched types
--> src/test_trace.rs:10:1
|
10 | #[xdp]
| ^^^^^^
| |
| expected enum redbpf_probes::xdp::XdpAction, found enum std::result::Result
| this expression has type redbpf_probes::xdp::XdpAction
|
= note: expected enum redbpf_probes::xdp::XdpAction
found enum std::result::Result<_, _>

error[E0308]: mismatched types
--> src/test_trace.rs:12:12
|
12 | if let Some(transport) = ctx.transport() {
| ^^^^^^^^^^^^^^^ --------------- this expression has type std::result::Result<redbpf_probes::net::Transport, redbpf_probes::net::NetworkError>
| |
| expected enum std::result::Result, found enum std::option::Option
|
= note: expected enum std::result::Result<redbpf_probes::net::Transport, redbpf_probes::net::NetworkError>
found enum std::option::Option<_>

[MarkSwanson]

I looked at redsift/ingraind dns/main.rs (and it's Cargo.toml) for inspiration. I'm using:
(rustc 1.43.0-nightly (58b834344 2020-02-05)
[dependencies]
cty = "0.2"
redbpf-macros = { git = "https://github.com/redsift/redbpf" }
redbpf-probes = { git = "https://github.com/redsift/redbpf" }

[build-dependencies]
bindgen = "0.51"
redbpf = { git="https://github.com/redsift/redbpf.git", features = ["build"] }

[features]
default = []
probes = []

[[bin]]
name = "test_trace"
path = "src/test_trace.rs"
required-features = ["probes"]

I also switched to using the preludes. Code looks like this:

#![no_std]
#![no_main]
use redbpf_probes::xdp::prelude::*;

program!(0xFFFFFFFE, "GPL");

#[xdp]
pub extern "C" fn block_port_80(ctx: XdpContext) -> XdpAction {
if let Some(transport) = ctx.transport() {
if transport.dest() == 80 {
return XdpAction::Drop;
}
}
XdpAction::Pass
}

But I still get the same errors.

error[E0152]: found duplicate lang item panic_impl
--> src/test_trace.rs:10:1
|
10 | program!(0xFFFFFFFE, "GPL");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this macro invocation
|
= note: the lang item is first defined in crate std (which test_xdp depends on)

error[E0308]: mismatched types
--> src/test_trace.rs:12:1
|
12 | #[xdp]
| ^^^^^^
| |
| expected enum redbpf_probes::xdp::XdpAction, found enum std::result::Result
| this expression has type redbpf_probes::xdp::XdpAction
|
= note: expected enum redbpf_probes::xdp::XdpAction
found enum std::result::Result<_, _>

error[E0308]: mismatched types
--> src/test_trace.rs:14:12
|
14 | if let Some(transport) = ctx.transport() {
| ^^^^^^^^^^^^^^^ --------------- this expression has type std::result::Result<redbpf_probes::net::Transport, redbpf_probes::net::NetworkError>
| |
| expected enum std::result::Result, found enum std::option::Option
|
= note: expected enum std::result::Result<redbpf_probes::net::Transport, redbpf_probes::net::NetworkError>
found enum std::option::Option<_>

[MarkSwanson]

Strange. I created the project again in a new dir and the program! macro worked fine. Maybe some rare condition where I switched Cargo.toml to use the git repo and some older cached compiled code was still getting used.
I just had to adjust some Option/Result handling and it compiled fine.
(2 warnings, but I'm sure you know about those)
warning: due to multiple output types requested, the explicitly specified output file name will be adapted for each output type
warning: ignoring --out-dir flag due to -o flag

I did use a temporary 'u32' as the eBPF function's Result Error type. Some guidance in the docs would be helpful/appreciated for this Error type. It's not entirely obvious to me how this error would be used by the kernel.

[rtkaratekid]

@MarkSwanson if you look at the other issue I've left open, you'll see that @rsdy mentioned the API is in flux right now. I just came back today to ask if it's a bit more stable.

I think until documentation is a little better and/or the API is a bit more stable it might be good to let rsdy handle it? I don't know. I want to contribute to the project, but don't want to get in the way if it's a matter of refactoring and I don't understand the library as well as him. Heck, I'd be happy to help keep documentation up to date so the API can be clearly understood.
In the meantime I've been messing with rust-bcc which doesn't meet my needs completely, but it does allow me to keep my data-handling userspace code the same if I decide to port over to here.

I'd love to get an update and/or hear what @rsdy has to chime in with.

[MarkSwanson]

I'm just playing. I don't mind if @rsdy fluxes :-) the API hourly :-)
Still, I am curious about propagating Error values to the kernel.

[rtkaratekid]

Yeah, don't know if I can tell you too much about the Errors right now as I haven't messed with the library in a couple weeks, but I'll probably start poking around again this week because you're making me all excited about this library again ;)

[MarkSwanson]

I'm going to close this because it compiles fine on a couple of machines. The error must have been a rare issue on my side.

[rsdy]

@MarkSwanson @rtkaratekid check out the release notes at https://github.com/redsift/redbpf/releases/tag/v0.9.13

We are going to slow down with the API changes now, and focus on documentation and iron out any remaining issues with the tooling before releasing 1.0.

According to my local runs, examples in the docs should also now be up to date.