Alternative libelf implementation

[DavidVentura]

Hi

I'm using libbpf-sys in a statically compiled binary, which is somewhat inconvenient to build due to elfutils and reliance on glibc.

Would you be open to integrating a separate libelf backend into this crate? It would complicate build.rs a bit (no zlib/elfutils needed)

I made this crate to provide the libelf C-API; it uses object to do the actual elf operations, and only has code to deal with the mistmached APIs. I don't think the implementation is great, and it's definitely not complete, but it does work for my specific use-case (loading programs with libbpf-sys)

[danielocfb]

We should probably wait for @alexforster 's take, but personally I'd be very much in favor of having an opt out from the C dependencies available -- building them is nothing short of a mess. That being said, I'd be reluctant to integrate with some just thrown over the fence kind of thing (I understand it's early stages, but given there is no track record of the crate being used it's questionable if it will be maintained down the line). So at the very least I'd want to see a test suite of public function and Miri passing on the bindings, to the degree that is possible. It would also obviously need to be published to crates.io (probably wise to rename the crate and then squat libelf-rs there while it's for the taking).

[DavidVentura]

That being said, I'd be reluctant to integrate with some just thrown over the fence kind of thing

I understand -- I made this crate specifically to see what the problem looks like and to have a discussion about the idea. I didn't intend to propose this specific crate (or, its current state) as something to include into this repo.

I'd be very much in favor of having an opt out from the C dependencies available

That's good to hear

[DavidVentura]

I've reserved the crate on crates.io and ran libbpf's fuzz tests for a bit over an hour with my lib, it converged at 32% coverage. I'll add some tests during the week, then we can discuss whether it's a promising direction or whether you consider the upside to not be worth the effort.

[alexforster]

Would you have any interest in maybe trying to "upstream" this into libbpf-sys? I'm fine with the idea, but do you really want to commit to maintaining this dependency for years? If the code lives in this repo, then we'll at least have a few other people around to merge PRs and triage bugs.

[DavidVentura]

Oh, I'd rather upstream!

[danielocfb]

The benefit of having it maintained outside of libbpf-sys would be that it can be reused outside of the context of this specific library -- I can see merit in it being available for other Rust projects that otherwise have to depend on the C thing. Of course theoretically it is reusable if published separately, but from my point of view it's just a distinct entity and having it co-located with libbpf-sys basically discourages adding support for functionality that libbpf-sys doesn't need directly.

Perhaps a good middle ground would be to move it into the libbpf org instead of coupling it with libbpf-sys too tightly.

[alexforster]

That would also work to solve my only concern (unmaintained dependencies).

[DavidVentura]

If you think it's promising, I can start working on this. My preference would be dedicated repos; putting them under this org is fine.

For this, we would also need a zlib replacement, for bpf_object__read_kconfig_file. zlib is much simpler, maybe it's better to start there?

[danielocfb]

Sounds good to me.