3 ms·
Cloud vms are a main target for unikernels, however, as Russ mentions in one of the linked issues there actually is quite a lot of other code you need to includ
by eyberg 1y ago
Cloud vms are a main target for unikernels, however, as Russ mentions in one of the linked issues there actually is quite a lot of other code you need to include in your system depending on what you are deploying to.
For instance systems with arm64 might need UEFI or if you enable SEV now you need additional support for that which is why I'd agree with Russ's stance on this.
Every time someone asks us to provide support for a new cloud instance type (like a graviton 4 or azure's arm) we have to go in and sometimes provide a ton of new code to get it working.
- kfreds 1y agoI assume you're referring to this[1]. I don't think it's necessary to bring all of that into the Go runtime itself, or ask the Go team to maintain it. It would be part of your application, and similar to a board support package. TamaGo already supports UEFI on x86, and that too would be part of the BSP for your application, not something that would need to be upstreamed to Go proper. Same for AMD SEV SNP. As for you (nanovms) supporting new instance types, wouldn't it be nice to do that work in Go? :) Edit: I wonder how big the performance impact would be if you used TamaGo's virtio-net support instead of calling from Go into nanos.