net_lattice_platform/capability.rs
1bitflags::bitflags! {
2 /// Runtime-dependent operating system features that cannot be expressed
3 /// through Rust trait implementation alone.
4 ///
5 /// Distinct from provider traits: a backend either implements
6 /// `RouteProvider` or it doesn't, and that's fixed at compile time.
7 /// Whether the *running* kernel has, say, VRF support enabled is a fact
8 /// about the current machine, not the crate — see ARCHITECTURE.md's
9 /// `net-lattice-platform` section.
10 ///
11 /// Capabilities describe the backend's view when queried; callers should
12 /// still handle operation errors because permissions or system
13 /// configuration may change later. Use them as a portable feature gate,
14 /// for example:
15 ///
16 /// ```ignore
17 /// if lattice.supports(Capability::MONITORING) {
18 /// let watcher = lattice.watch()?;
19 /// }
20 /// ```
21 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
22 pub struct Capability: u64 {
23 const IPV6 = 1 << 0;
24 const VRF = 1 << 1;
25 const NAMESPACES = 1 << 2;
26 const MONITORING = 1 << 3;
27 /// The backend can replace resolver configuration through a supported
28 /// operating-system mechanism.
29 const DNS_MUTATION = 1 << 4;
30 }
31}
32
33/// Reports which runtime-dependent [`Capability`] flags the connected
34/// backend currently has available.
35///
36/// Every backend implements this (it costs nothing when there's nothing to
37/// report — an empty flag set is a valid answer), which is why `capabilities`
38/// returns a bare `Capability` rather than `Result<Capability>`: unlike the
39/// other provider traits, there is no OS call here that can fail in a way
40/// worth surfacing to the caller. `addresses`-style methods that really do
41/// call into the OS keep returning `Result`.
42pub trait CapabilityProvider {
43 fn capabilities(&self) -> Capability;
44}