Re: [PATCH] Documentation: Architecture Decision Record

Alyssa Ross
2023-01-06T13:27:59Z

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

On Mon, Jan 02, 2023 at 11:03:43PM -0800, Adam Joseph wrote:
> Quoting Ville Ilvonen (2022-07-08 04:02:15)
> > +++ b/Documentation/decisions/006-drivers-on-host.adoc
> > ...
> > +## Consequences
> > +No networking on the host. Responsibilities of the host are expected to get
> > +smaller over time.
>
> I know you're probably a long, long way from worrying about wifi, but when you
> get to that point, I suggest taking a look at running `eiwd` in the netvm:
>
> https://github.com/illiliti/eiwd/
> https://github.com/NixOS/nixpkgs/pull/208844
>
> - It is way more robust than wpa_supplicant.
> - (unlike iwd) it does not require plumbing a dbus connection from the hostvm to
> the netvm (nor all the attack surface that would entail).
> - You control it by simply editing its state files, which it watches with
> `inotify()`.
> - It has zero runtime dependencies!
> - `pkgsStatic.eiwd` builds (caveat: I have not tested it)
> - You should be able to boot a VM with `init=/nix/store/...-eiwd/bin/eiwd`
> and run it as PID 1 (note: I have not tried this).
>
> I've been running this on my daily driver laptop for the last few weeks and am
> extremely happy with it.

Thanks for the recommendation!

IMO, we're not too far away from worrying about Wi-Fi — it would just
involve setting up Wi-Fi modaliases to pass through to the appropriate
VM, and setting up the VM to do the right thing if any Wi-Fi devices
were connected to it.

For embedded use cases, where you could just bake the network
configuration in to a custom netvm, that'd be it. But for e.g. a
laptop, for Wi-Fi to be useful we'd really need a way to have persistent
storage for on-the-fly network configuration. That's the main reason I
haven't looked at Wi-Fi yet. It's a very pressing problem, though, so
hopefully won't be too long...