With all the interest in rayhunter, I think it’s going to get more important to have some way to gate features on a per-device basis.
That way if we have a dev create something and test it on 1 or 2 devices we could merge it in, but have it only enabled on those devices. A feature flag of sorts. That way if there’s new devices which can’t reliably support a feature we can also turn that off.
Here’s my pitch
The approach I’ve been mulling over is to have a deps.toml which has the device types, features, and dependencies of those features. This enables us to understand two important things. The first is what functionality is dependent on a feature (even if that’s a transitive dependency and not direct). Second it gives us a way to list the features in a consistent way.
New features are being developed that can’t be tested on all 6 supported devices. deps.toml already tracks which features belong to which devices, but nothing enforces this — all device code compiles into every binary and there’s no runtime validation. The goal is to make the deps.toml device mapping actionable at both build time and runtime, so features can be progressively enabled per device as they’re tested.
Three layers, implemented incrementally:
- deps generate: generates a Rust capability map from deps.toml (source of truth)
- Cargo device features: #[cfg]-gate device-specific modules (display, battery)
- Runtime validation: daemon warns/disables features unsupported on the configured device
For example here’s a quick mockup of how this may work https://github.com/EFForg/rayhunter/pull/898
This is partially in response to the mockup:
I think in general I agree with this but I don’t think we should compile separate daemon files per device, runtime feature flagging seems enough to me for most cases. I think that if we have features that really do add a large amount of space, we could have
rayhunter-daemon,rayhunter-daemon-xlor something like that, which would end up being much fewer compile-time featureflags.I also question if we have to keep this toml file and build all the visualization tooling around it. I think maintaining a feature support matrix as a markdown table in the docs is probably good enough