Support for a new OS, VxWorks?

[Brian Kuhl]

Hi Go Developers,

I work for Wind River the company that owns VxWorks RTOS. The OS in more types computerized things on this planet and mars, than any other.  Recently the VxWorks development focus has been around increased language support. The device market is experiencing a consolidation of functionality, and what companies  want port onto an RTOS is increasing. We recently started supporting python and rust, and have updated to C++17.  We'd also like to support Go.

So I'm asking what the considerations are for up streaming  a contribution of VxWorks support for Go?

Do you want a feature proposal in you github tracking to start with?

Do want WindRiver to commit to anything in particular, other than having the contributors sign the contribution agreement?

From interface perspective VxWorks 7 looks a lot like another BSD variant, with a few things missing. It is always cross-compiled, so contribution would just run-time support.  I'd probably be doing the initial POC with an intern on amd64, but VxWorks currently supports 64/32bit on ARM, IA and PPC reference designs.  So we eventually be running regression against all that are available ( yes, I know ppc 32bit isn't there now.)

Assuming the Go community is open to this idea, I'd also like some advice on how to proceed, from anyone who has added OS support to Go in the past?

Many Thanks,

Brian Kuhl

 

[Brad Fitzpatrick]

On Fri, Nov 1, 2019 at 5:56 PM Brian Kuhl <kuhle...@gmail.com> wrote:

So I'm asking what the considerations are for up streaming  a contribution of VxWorks support for Go?

See https://golang.org/wiki/PortingPolicy

 

Do you want a feature proposal in you github tracking to start with?

It doesn't need to be a proposal, but a new issue like: 

     all: add vxworks port

... would be enough, so changes can all reference it.

Do want WindRiver to commit to anything in particular, other than having the contributors sign the contribution agreement?

Just the stuff at https://golang.org/wiki/PortingPolicy --- an owner and builder(s).

 

From interface perspective VxWorks 7 looks a lot like another BSD variant, with a few things missing. It is always cross-compiled, so contribution would just run-time support.  I'd probably be doing the initial POC with an intern on amd64, but VxWorks currently supports 64/32bit on ARM, IA and PPC reference designs.  So we eventually be running regression against all that are available ( yes, I know ppc 32bit isn't there now.)

If you need ppc32, did you consider targeting gccgo instead of the Go cmd/compile? That might be an easier path if you already support gcc. (Go has multiple compilers... this mailing list is primarily about the golang.org one, previously named lowercase gc, nowadays named cmd/compile)

 

Assuming the Go community is open to this idea, I'd also like some advice on how to proceed, from anyone who has added OS support to Go in the past?

You can look at the git history for examples of the typical change chunk sizes for new ports in the past. To find things to grep for in the git log, see old release notes:

https://golang.org/doc/go1.7#ports

https://golang.org/doc/go1.8#ports

https://golang.org/doc/go1.9#ports

https://golang.org/doc/go1.10#ports

https://golang.org/doc/go1.11#ports

https://golang.org/doc/go1.12#ports

https://golang.org/doc/go1.13#ports

There have also been threads on golang-dev that you can search for where people give advice on the best order, such as https://groups.google.com/forum/#!topic/golang-dev/SRUK7yJVA0c/discussion