proposal: all: add plan9/arm64 port

[rafael2k]

Proposal Details

This is a revamped proposal to support plan9/arm64. More information in the MR: #76271

Many Plan9 users user arm64 as their daily use machine (eg. MNT Reform). Amd64 and arm64 have by far more users than 386 and ARM. Maybe having a 9front builder with a suggestion how to maintain could be promising.

Quoting @psilva261 on what changed since last attempt to upstream plan9/arm64 port:

• 386/amd64 builders had a lot of issues, however looking at build.golang.org the plan9/386 builder runs much more stable than when the previous proposal was open. Even the golang.org/x repos run through

• amd64 builder is being moved to LUCI (from what I understand this should make maintenance more scalable maybe): x/build: add LUCI plan9-amd64 builder #63600

• Builder access @oridb also created this issue to add me and @majiru as maintainers: access: plan9: add 9front developers to the plan 9 group #58011 also I could definitely help with that

• 9front now has qemu images for amd64 and arm64: https://9front.org/releases/2025/10/11/0/

Concerning bugs in the system itself

• 9front runs more reliably

• a lot of errors were actually filesystem related so ramfs was used. Well now there is gefs though https://orib.dev/gefs.html

• also in 9legacy together with Go monotonic time is now there https://9fans.topicbox.com/groups/9fans/T59810df4fe34a033/monotonic-time-and-randomness-on-plan-9

[seankhliao]

looking at #57540 there doesn't appear to be any new information that would justify reconsidering at this point in time.
The list of open issues for existing plan9 issues does not appear to have shrunk.

[rafael2k]

Why you say there is no new information @seankhliao? You seem misinformed.
9front had many years on improvements and bugs fixed in arm64, and is more stable and feature full (eg. atomic functions support), which you can track here:
https://github.com/9front/9front

Could you explain the rationale about this existing plan9 issues be the blocker for this work? There are already 386, arm and amd64 for plan9, but arm64 is not allowed? Arguably, it is much more important to have arm64 than 386 and arm.

[rafael2k]

If @psilva261 agrees, me and him could be the maintainers of the port.

[rafael2k]

@ianlancetaylor, @randall77, @adonovan, @rsc et al., could you please outline what needs to be done towards the acceptance of this port, and which failing tests are blocking the plan9 arm64 port?

I understand Plan9 support have no commercial interest at this point, and Google does not care about it, but considering the Go compiler and language itself, in many aspects, came from Plan9, I think it would be nice to consider this port, especially for research and future experiments with cloud-native applications on Plan9. There is obviously no rush with this work, but having the first iteration on this topic with "Closed as not planned" is not optimal.

[psilva261]

Yeah there are the issues which pop up from the builders. Solving these seems to consist of multiple chicken-egg problems which would have to be untangled. Although from what I understand some of these underlying issues are much better now.

• 386/amd64 builders had a lot of issues

  • however looking at build.golang.org the plan9/386 builder runs much more stable than when the proposal was open. Even the golang.org/x repos run through

  • amd64 builder is being moved to LUCI (from what I understand this should make maintenance more scalable maybe) x/build: add LUCI plan9-amd64 builder #63600

  • Builder access @oridb also created this issue to add me and @majiru as maintainers: access: plan9: add 9front developers to the plan 9 group #58011 also I could definitely help with that

  • 9front now has qemu images for amd64 and arm64 https://9front.org/releases/2025/10/11/0/

• Bugs in the system itself

  • 9front runs more reliably

  • a lot of errors were actually filesystem related so ramfs was used. Well now there is gefs though https://orib.dev/gefs.html

  • also in 9legacy together with Go monotonic time is now there https://9fans.topicbox.com/groups/9fans/T59810df4fe34a033/monotonic-time-and-randomness-on-plan-9

Maybe trying to have a 9front builder with a suggestion how to maintain it could be more promising. (Also what happens if new bugs in the system are discovered which break the build? While I'd like to help where possible, I wouldn't know how to solve such issues in general) Maybe it's also a good idea to raise this on the 9fans Mailing list

[Jorropo]

@rafael2k if you go and read #57540 it states:

It sounds like the sentiment is we should focus on the existing plan9 ports before adding a new one. Do I have that right?

There is also a laundry list of issues here:
#57540 (comment)

Your proposal doesn't include information (the proposal must be the thing everything else link to not the other way around).
Your MR contains a single piece of information:

32-bit are staying in the past

Which is not why #57540 was refused.

If I allow myself to summarize #57540:

Plan9 has very little users, yet it breaks more often than other GOOSes.
Making it a poor maintainer time investment to keep it alive.
Thus if keeping it alive is uncertain* we do not want to add yet an other plan9 target.

*:

I have been wondering whether it should be moved out of the main repository or if there should be a push to try to bring it back closer to parity.

---

If you want this to be accepted you need to change this proposal to explain why the situation is different.
You also need to explain why adding plan9/arm64 will not slow down the development of other targets who have significant amount of users.

You might want to take inspiration from @psilva261's message right here: #76272 (comment).
It explains how part of the situation changed ever since #57540.

[rafael2k]

Thanks a lot @psilva261 and @Jorropo. I'm re-organizing the proposal text so to make clear the situation is definitely different, and it will not slow down development (even more?) compared to already having 3 Plan9 archs onboard.

[thepudds]

FWIW, see this section and the corresponding link from https://go.dev/s/proposal:

Generally speaking, our approach to reconsidering previously decided proposals follows John Ousterhout's advice in his post “Open Decision-Making,” in particular the “Reconsideration” section.

In particular, it's worth reading that "Open Decision-Making" link.

In short, there would essentially need to be new information to revisit a previously decided proposal.

Perhaps it could be worthwhile to start a thread on one of the plan9 mailing lists to discuss what might be done.

---

Also, I will note that there was some discussion in #73608 to possibly extend that proposal for GOOS=none for "bare metal" support to also include some less commonly used OS ports, possibly including plan9. One plausible outcome of that discussion might be a definition of GOOS=custom (or whatever name), which might end up covering plan9 needs as well, though I think it is probably premature to guess at how that discussion will turn out.

Some sample comments from #73608:

#73608 (comment):

2. Alternatively, as a "framework" for making it easier to maintain out-of-tree ports. Making it easier to maintain out-of-tree ports was a major discussion point on proposal: all: add bare metal ARM support #46802. In this light, I think it is much more reasonable to say we intend this to be reasonably stable, but don't have a full compatibility promise and still expect port maintainers to keep up with changes in new Go versions.

#73608 (comment):

Do you think it's plausible that what you've explored here could become a general-purpose abstraction layer to aid in new ports to actual operating systems, rather than only to bare-metal?

Specifically I'm thinking of a model where certain GOOS values could be mapped to either in-tree or out-of-tree Go modules that would get automatically linked in by the toolchain whenever that GOOS is selected, and would provide the same supporting machinery that would've been provided by the end-developer in the bare metal situation you described, but packaged up in a reusable form separate from the application.

#73608 (comment):

Maybe we could call it GOOS=custom since it allows customizing the OS interface. It also feels like a better fit than GOOS=noos if we end up moving e.g. plan9 to this framework.

[rafael2k]

Concerning the proposal formalities:

The proposal author [creates a brief issue](https://go.dev/issue/new) describing the proposal.
Note: There is no need for a design document at this point.

I think I did that. @seankhliao promptly rejected the proposal, without discussion. I assume it is my bad I did not add much information in the proposal, sorry. I'm adding now.

Years passed since past plan9/arm64 port attempt, 9front arm64 port got much more mature, and the OS itself got more stable and gained needed features (proper monotonic clock support, new performant fs gefs, atomic load/store APIs, etc).

@prattmic just suggested in Gerrit to open a proposal... and mentions "It is nice that the total diff is quite small".

Should I open a new proposal with clear intent and reasoning, so it does not get closed instantaneously?

[seankhliao]

Proposals need to convey sufficient information for them to be evaluated.
A look at existing proposals under review should tell you what the expectations are.
One line certainly does not cut it, especially for a proposal that's been rejected before.
https://github.com/golang/proposal?tab=readme-ov-file#declined-as-duplicate

If you do open a new proposal, please carefully go over the comments in the previous proposal and properly address the concerns raised there, with evidence to back why the situation is different enough to be worth reconsidering.

[rafael2k]

Thanks for the references.

The proposal here was declined as "Not planned", not as "Duplicate". In this case, by reading the document on how to do a new proposal, it seems there is a "Premature Conclusion", as just some hours passed since the posting of the proposal and the rejection - no discussion or time for arguing.

I see:

Proposal Review
A group of Go team members holds “proposal review meetings” approximately weekly to review pending proposals.

I apologize in advance in case I'm not getting the process correctly.

[seankhliao]

Also #49338 is a particularly noisy thread, I would expect less issues if plan9 is as stable as claimed.