Yeah but I don't want to have to define a feature for each kernel version and configuration. I've thought about it though and I guess I could detect the kernel version and config in a build script and enable the proper features. But that doesn't seem very nice...
It depends on your constraints and what is/isn't acceptable, but one strategy I'd look at is defining multiple versions of the type and detecting which version to use at runtime.
As a bonus, this method means downstream users won't get spurious compiler errors when build with a different kernel version than the one you tested with. It also avoids infecting half your codebase with #[cfg(kernel_is_older(4.2.1)] annotations.
Originally you had a pre-4.2.1 option and a post-4.2.1 option. Why can’t you do that with features? I don’t see the need to make one for each version if that’s not what you wanted.