No support for 32-bit?

[mimullin-bbry]

The new explicit padding is explicit for 64bit data alignment. Can eBPF used on 32bit machines?

I'm sorry, but I do not have a 32 bit machine to verify whether this is an issue or not.

[alexforster]

The structs in the Linux uapi headers all take care to handle alignment correctly, but libbpf itself is not nearly as careful. For example, this struct...

struct bpf_xdp_set_link_opts {
	size_t sz;
	int old_fd;
	size_t :0;
};

16 bytes on 64-bit: https://c.godbolt.org/z/nncsbM6sz
8 bytes on 32-bit: https://c.godbolt.org/z/cxvGvzaqT (same link as above, with -m32 compiler option)

Given that lots of software and distros are removing 32-bit support, I think it's fine. In case there are users out there who want 32-bit support, I'm going to rename this issue and leave it open. If you're a 32-bit user who comes across this, please leave a comment!

[mimullin-bbry]

I am not a 32 bit user. I just didn't want you to be sideswiped by possible issues for a change you made on my behalf (re: explicit defaults).

[alexforster]

@danobi thoughts on 32-bit support?

[danobi]

I believe libbpf and libbpf-rs have special cases for 32 bit arches. I probably wouldn't spend a lot of effort on getting 32 bit support in but it'd be nice if it existed.

[anakryiko]

libbpf itself is not nearly as careful.

Why not careful? Yes, size_t is 64-bit on 64-bit architecture and 32-bit on 32-bit architecture. You need to compile libbpf for your target bitness and everything works. So libbpf definitely is designed to work on 32-bit architectures, you can't just compile it once and run the same binary artifacts on both 32-bit and 64-bit architectures.

[alexforster]

Sure, that's fine in C, but having structs change size or alignment depending on word size (or even worse, compiler flags!) makes FFI much harder in all languages, not just Rust.

[anakryiko]

Rust doesn't support conditional compilation depending on target architecture bitness? Or it's just too much trouble to generate two sets of bindings (one for 64-bit and another for 32-bit targets) and pick one of the at the compilation time? But I never done that, so not suggesting anything. On libbpf side we can't change things (and it's generally impossible to guarantee exact same struct memory layout with stuff like pointers in OPTS structs anyways, unless we unionize everything w/ u64 to ensure 64-bit alignment and appropriate padding). So not sure what else can be done here :(

[alexforster]

Or it's just too much trouble to generate two sets of bindings (one for 64-bit and another for 32-bit targets) and pick one of the at the compilation time

Basically. In an early version, I had the build script generate the bindings on users' machines at compile-time. Later, I switched to pregenerating the bindings, because it makes the library compile much faster.

We have three options:

• Go back to generating bindings at compile-time
• Pregenerate bindings using a 32-bit toolchain and a 64-bit toolchain, and then conditionally compile one of them in
• Drop 32-bit support

On libbpf side we can't change things [...]

Agree, and I honestly prefer just dropping 32-bit support unless/until someone needs it.

On that note, I'll mention it again – if you're reading this and you're a 32-bit user, please let me know!

[anakryiko]

Or it's just too much trouble to generate two sets of bindings (one for 64-bit and another for 32-bit targets) and pick one of the at the compilation time

Basically. In an early version, I had the build script generate the bindings on users' machines at compile-time. Later, I switched to pregenerating the bindings, because it makes the library compile much faster.

We have three options:

* Go back to generating bindings at compile-time

* Pregenerate bindings using a 32-bit toolchain and a 64-bit toolchain, and then conditionally compile one of them in

* Drop 32-bit support

On libbpf side we can't change things [...]

Agree, and I honestly prefer just dropping 32-bit support unless/until someone needs it.

Yep, sounds good. But if we needed 32-bit badly, option #2 is the way to go, IMO.

On that note, I'll mention it again – if you're reading this and you're a 32-bit user, please let me know!

[alexforster]

Note: as of the current release, you can now generate bindings during build time using a new feature flag called bindgen, like so:

libbpf_sys = { version = "...", features = ["bindgen"] }

In the future, I plan on pre-generating bindings for Rust's tier 1 platforms.