tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Moving Go to a newer NetBSD ABI in the 1.13 dev cycle

Benny Siegert <> writes:

> To keep up with supported versions, I would like to move Go to use
> syscall number tables for NetBSD 7 (or perhaps even 8?) and move the
> ELF identification to version 7.0 or 8.0. Trying to get this done in
> time for Go 1.13.
> Any comments, objections, etc. from Go or NetBSD folks?

I think you should try to keep go working on NetBSD 7.  While the branch
is, someday, going to to stop receiving fixes, it seems a bit much to
have a language necessary for significant things stop working unless
there are really compelling reasons.

As I understand you, the only reason to pick 8 instead of 7 is to avoid
having to have some kind of COMPAT_7 option in the kernel.  Surely 8 and
almost certainly 9 are going to have that, so that people can upgrade.
So I don't see the gain other than perhaps reducing the time to the next

I don't understand your point about 7 and Spectre/Meltdown.  That's of
course one of many reasons for people to upgrade, but I don't see that
it's a reason to break go on 7, harming people that are making choices
to stay on 7 due to considerations we don't know about.  As I see it,
it's ok to desupport go on a system when the pain of keeping it working
outweights the pain of the people that lose it, adjusted by some sort of
metric about whether they should instead update.  People running 6
should already have updated, but 7 is today stable and supported.

Also, I don't understand go innards, but it would be nice to not need
this kind of pinning.

Is it possible to set a target ABI that is different on different
systems, building go on 7 for 7, and on 8 for 8?  That must be hard, or
you wouldn't be asking what you are asking... (resident old system and portability crank)

Home | Main Index | Thread Index | Old Index