Consider using `bit_field` crate for accessing bitfields

[thomaseizinger]

Would you be happy in replacing the current bitfield code with https://docs.rs/bit_field and just using u8s (or arrays where necessary) to represent the actual fields?

I think that would be a lot more ergonomic but it would add 1 dependency (which doesn't have any other dependencies).

[thomaseizinger]

Hmm, I just saw that this does have assert!s in the code which I am not sure the compiler will be able to optimise out?

[thomaseizinger]

The bitfield crate isn't very complicated, we could adopt a similar approach in here perhaps, i.e. using a trait instead of a dedicated type but without any panic paths so it is more eBPF friendly?

[vadorovsky]

I'm in favor of that, the bitfield implementation from bindgen is horrible.

Hmm, I just saw that this does have assert!s in the code which I am not sure the compiler will be able to optimise out?

Yes, that's a no-go for eBPF code. Another red flag is that it wasn't updated in 2 years.

The bitfield crate isn't very complicated, we could adopt a similar approach in here perhaps, i.e. using a trait instead of a dedicated type but without any panic paths so it is more eBPF friendly?

I like the idea.

Another option would be https://github.com/gregorygaines/bitfields-rs, but I've never tried it, so I don't have any opinion yet. It also doesn't have any runtime dependencies.

[thomaseizinger]

Another option would be https://github.com/gregorygaines/bitfields-rs, but I've never tried it, so I don't have any opinion yet. It also doesn't have any runtime dependencies.

Interesting, I wonder if it generates repr(C) annotations and/or is compatible with it.