# `Linx.Netfilter.Vmap`
[🔗](https://github.com/oshlabs/linx/blob/v0.2.0/lib/linx/netfilter/vmap.ex#L1)

Constructor sugar for verdict maps — a `Linx.Netfilter.Map` with
`:data_type` fixed to `:verdict`.

Verdict maps (vmaps) are the kernel's rule-dispatch primitive:
one lookup turns "if dport is 22 jump ssh, if 80 jump http, if
443 jump https, ..." from a wall of rules into a single hash
lookup. The Kubernetes kube-proxy nftables backend leans on this
shape; so does any non-trivial firewall.

## Construction

    iex> Vmap.new("port_dispatch", key_type: :inet_service,
    ...>          elements: [{22, :jump_ssh_in}, {80, :jump_http_in}])

In the example above the values are passed in the user-friendly
verdict-input form; `Linx.Netfilter.Map` normalises each to
`%Linx.Netfilter.Verdict{}` (the `:verdict` data_type accepts any
input `Verdict.new!/1` understands).

Returns a `%Linx.Netfilter.Map{}` (with `data_type: :verdict`) —
there is no separate `%Vmap{}` struct, just this constructor and
the underlying map.

# `new`

```elixir
@spec new(
  String.t(),
  keyword()
) :: {:ok, Linx.Netfilter.Map.t()} | {:error, {:bad_map, term()}}
```

Builds a verdict map. Accepts the same options as
`Linx.Netfilter.Map.new/2` except `:data_type` (which is forced
to `:verdict`).

# `new!`

```elixir
@spec new!(
  String.t(),
  keyword()
) :: Linx.Netfilter.Map.t()
```

Bang variant of `new/2`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*