search

little-dude / netlink

netlink libraries for rust
Other
328 stars 89 forks source link

Avoid defining kernel dependent data structures. #44

Open pinkisemils opened 5 years ago

pinkisemils commented 5 years ago

Currently, netlink-packet::rtnl::link::inet6::dev_conf::LinkInet6DevConfBuffer is trying to mirror the kernel's ipv6_devconf struct as defined in /lib/modules/$(uname -r)/build/include/linux/ipv6.h. Since certain fields in ipv6_devconf are dependent on the kernel config, it'll be hard to ensure that this crate is ever 100% compatible with the machine it's running on. For instance, the dump_links example will not work on Debian 9. I'm unsure if there are any other structs that are kernel config dependent, but there might be.

Whilst I cannot envision nice and fluffy solution to this issue immediately, treating the device config (or any structure that can change from kernel to kernel) NLA as an opaque byte buffer would be a solution. Then a different crate can be used to try and deal with the multiplicity of different ipv6_devconf definitions.

For anyone looking for a patchy solution, there's this branch which hacks around the expectation of a specific length of ipv6_devconf, but there might be other kernel-dependent structs.

little-dude commented 5 years ago

Hello,

I did not even realize there were config dependent structs :(

I can't see an immediate solution either at this point, so yeah, keeping those a Vec<u8> might be better for the time being.

(I'll be AFK for the next 15 days, so won't be able to comment further)

squeed commented 5 years ago

I'd been toying around with my own netlink library (though it's high time I gave it up and switched to this), and I pulled these in with bindgen. While binaries won't work cross-platform, it does fix local compilation...

little-dude commented 2 years ago

FWIW it seems that the current best solution is to use different features for difference kernels: https://users.rust-lang.org/t/defining-custom-cfg-predicates/72610/4

cathay4t commented 2 years ago

The Debian 9 is not supported any more as stated by https://www.debian.org/releases/stretch/ I don't see a point of support its kernel. Something not working in Debian 9 is not a good reason here.