Skip to main content

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}