You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 7, 2021. It is now read-only.
@joshtriplett proposes that the first driver we try to get into the upstream kernel should be some neat virtio thing, alongside an implementation in qemu (and maybe also one of the virtio hypervisors in Rust!). This would have the benefit of letting people play with it in a VM and also make it non-critical, so we can enable it in defconfig if you have Rust nightly installed and are on a compatible arch (in particular, we're neither duplicating nor replacing an existing driver).
Maybe there's some interesting channel we can virtualize - the concept of virtio-wayland was mentioned as inspiration.
The text was updated successfully, but these errors were encountered:
virtio-midi - it's a pretty simple protocol, it'll be fun, it won't be in anyone's way
Google has a virtio-based Android "Cuttlefish" platform for testing, running on crosvm, their maintainers might have more virtio things they'd like support for
@joshtriplett proposes that the first driver we try to get into the upstream kernel should be some neat virtio thing, alongside an implementation in qemu (and maybe also one of the virtio hypervisors in Rust!). This would have the benefit of letting people play with it in a VM and also make it non-critical, so we can enable it in defconfig if you have Rust nightly installed and are on a compatible arch (in particular, we're neither duplicating nor replacing an existing driver).
Maybe there's some interesting channel we can virtualize - the concept of virtio-wayland was mentioned as inspiration.
The text was updated successfully, but these errors were encountered: