Golang port for ESXi

[Yash Desai]

Hey folks,

I'm Yash, working for VMware. We have a port of golang for our ESXi Operating system (GOOS=esx, GOARCH=amd64). 

I write this email to discuss upstreaming our port and merging it into the core go tree, as a non-first class port.

Golang on ESXi: 

The golang port is used by a handful of production services on ESXi. One such service is spherelet, which is based on virtual kubelet.

Used in production, means we plan to continue using and supporting this port of golang for ESXi.

The port is based on TOT Golang and the devboringcrypto patches, keeping it updated with upstream minor releases. So far, we have shipped golang versions 1.13 to 1.17 and working on 1.18.

Scope of patches for port:

While ESXi is not Linux and has differences, especially around memory management, it is POSIX-like with support for glibc. This means we have a straightforward port of golang, based on the Linux port, with limited ESXi-specific code.

Upstreaming the port:

I have reviewed the porting wiki and understand the requirements for a developer and builder (build system).

Note: this is for a non-first-class port. 

I have some follow-up questions, which will help our leadership make a more informed decision:

1. What's the SLA/ETA requirement for the developer to fix broken builds?
   
2. What's the SLA/ETA requirement for the developer to respond to architecture-type decisions which might affect our port?
3. What's the approximate developer resource commitment required? I understand the actual number is hard to guess, but it will help understand the time commitment based on other ports.
4. Is it ok to have a team of engineers who rotate through this duty (in say a monthly cadence for example)?

I'm happy to get on a call or engage in other forms to get answers and discuss this more before we finalize and figure out the next steps.

Regards,

Yash

[Ian Lance Taylor]

This would be a secondary port. There is an active, not yet accepted,
proposal that discusses some of your questions at
https://go.dev/issue/53383.

I don't have a good answer for the resource commitment. It's going to
depend on how different the port is. The memory management code in
the runtime package doesn't change often but it does change sometimes.

Having a rotating team of engineers is fine.

Ian

[Olivier Ruff]

Dear Yash Desai,

It would be great if VMware could share this port with the community.

I have a few golang utilities that I had to rewrite in Python...

Best Regards.