syscall: how to deal with ABI changes? (freebsd in this case)

[keltia]

Hello,

1. What version of Go are you using (go version)?
   1.6 & 1.7 & master 1.8
2. What operating system and processor architecture are you using (go env)?
   FreeBSD 9.x / 10.3 / upcoming 11.0

An interesting problem: between 8.x and 9.x in 3/2014 (see freebsd/freebsd-src@b38edcd#diff-6769d113f5fa92d186538ae4c8659029) some structures were changed in the kernel ABI (and thus breaking it). Current Go repo has a copy of the 8.0 if.h file translated in go struct. How would you deal with such an ABI change with respect to the go translation?

In the current FreeBSD port system, we have an patch that re-sync with the current ABI (although it is currently incomplete as it does not deal with ztypes_freebsd_arm.go at all but I'll fix that) and I'd like to see that patch (see https://github.com/freebsd/freebsd-ports/blob/master/lang/go/files/struct-if_data-patch) upstreamed if possible.

The problem is that I'm not sure how (and have some difficulty to test right now) a go compiled binary with the modifications would work on a pre-ABI change system (although it is rather old and unsupported right now, I'd hate to break that) and how, in the go side of things, deal with that (versioned *_freebsd_* files? Something else?).

Thanks.

[ianlancetaylor]

As far as I can tell, FreeBSD changes ABIs more aggressively than most systems. The FreeBSD port maintainers will have to decide how they want to handle this in Go.

[bradfitz]

@keltia, the patch you link to is modifying the "syscall" package, which is frozen. We even document that at the top of the page (https://golang.org/pkg/syscall/), telling users to use https://godoc.org/golang.org/x/sys/unix etc instead.

The Go runtime itself doesn't always use the "syscall" package.

For instance, for the interface data, we actually vendor a copy of https://godoc.org/golang.org/x/net/route instead (into the standard library, privately) which has been updated for various FreeBSD versions.

What was the original problem which motivated the syscall patch? It looks like http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2015-August/315441.html but that was fixed in Go 1.7 by the x/net/route vendoring.

/cc @mikioh

[keltia]

@bradfitz thanks for the good news and go 1.7. I'll check with the port maintainer and remove the patch.
@ianlancetaylor we are getting better [at not breaking ABI] :)

[keltia]

@bradfitz the maintainer has committed the removal of the patch file and the port is now at 1.7, thanks!