Request: move `internal/computecore` and `internal/hcs` out of `internal/`

[AkihiroSuda]

https://github.com/microsoft/hcsshim/blob/main/internal/vmcompute/vmcompute.go https://github.com/microsoft/hcsshim/blob/main/internal/computecore/computecore.go is useful for third-party applications that call the HCS API.

Would it be possible to move internal/vmcompute internal/computecore (and ideally internal/hcs/... too) out of internal/ so that third-party applications can use this package without copying it?

[jterry75]

Akihiro Suda (@AkihiroSuda) - Historically we have considered the support boundary the shim Task interface and the vmcompute/computecore implementation an "internal detail". Are you asking that we export the syscall layer as a package? or that we export the entire object model, schema, etc?

[AkihiroSuda]

Thank you for replying.

Are you asking that we export the syscall layer as a package? or that we export the entire object model, schema, etc?

Ideally latter one.
The first step can be to just expose the former one.

[jterry75]

Saw your PR can I ask what this is for? Here is the current state of the order:

vmcompute.dll has been replaced by computecore.dll. This repository has support for both internally. computecore.dll is the only one we'd like to support in this repository moving forward. So, I'd be much more willing to export the syscall layer of computecore than vmcompute which we are trying to phase out but it's hard to know if you could do that until I know your scenarios.

[AkihiroSuda]

Updated PR to expose computecore.

• move internal/computecore out of internal #2825

Expected to used for implementing VM driver for Lima (https://lima-vm.io)

• Support for Windows hosts, without depending on QEMU lima-vm/lima#4961

[jterry75]

I just read that thread. Have you considered using OpenVMM+WHP for this purpose? Since your goal is not really anything to do with the containers that this repo is attempting to support, I'm not sure it makes sense to depend on it. You will also need us to export the at a minimum the virtual machines * schema and then all of the modify for the hotadd/hotremove scenarios. I'm not sure it makes sense for a generic hcs VM manager layer API here.

[AkihiroSuda]

Have you considered using OpenVMM+WHP for this purpose?

Thanks for the suggestion, however, the goal of lima-vm/lima#4961 is to eliminate the extra dependency (QEMU), so introducing another dependency on OpenVMM contradicts the goal (unless Windows begins to include OpenVMM).

If the exposition of internal/{computecore, hcs/schema2} is out of the scope of hcsshim, I think we can just copy the packages to our repo and call it a day.

[jterry75]

I think realistically I could talk to the team about exposing:

1. pkg/computecore
2. pkg/computenetwork
3. pkg/computestorage
4. pkg/schema2

Those I think we could easily support.

What I don't think we can support though is:

pkg/hcs - Maning some sort of library code base for interfacing and dealing with the syscall and schema layer. For that we only support the containerd Task interface as the boundary.

[AkihiroSuda]

I think realistically I could talk to the team about exposing:

Thanks, was it talked to the team?