3 ms·

For all the emphasis they put on stability, there is one part that doesn't seem particularly stable – on slide 32: "Go 1.11 supports the upcoming OpenBSD 6.4 r

by ptx 8y ago

For all the emphasis they put on stability, there is one part that doesn't seem particularly stable – on slide 32: "Go 1.11 supports the upcoming OpenBSD 6.4 release. Due to changes in the OpenBSD kernel, older versions of Go will not work on OpenBSD 6.4." This is, I assume, because Go makes direct syscalls rather than going through the C library. Many operating systems, including Windows, don't consider that a stable public interface. So does this mean that older Go binaries will stop working when you upgrade the OS? I guess that would make the source compatibility extra important to them, since you must keep recompiling your old programs as you upgrade to newer a OS. (Perhaps it's also why they're dropping support for older OS versions so quickly?)

LukeShu 8y ago
OpenBSD doesn't make any promises about ABI stability between releases. That means that all older binaries may stop working when you upgrade the OS, not just older Go binaries.
- zdw 8y ago
  This might be seen as a problem, but it allows the OpenBSD devs to push the envelope of expectations and find bugs across the entire software ecosystem. An example of this was the change to 64-bit time_t back in 2013 (talk: https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ ), and evolving syscalls like pledge(2) that changed syntax between releases as the problems/benefits of a specific implementation choices were learned.
AnIdiotOnTheNet 8y ago
> Many operating systems, including Windows, don't consider that a stable public interface. Windows in no way requires libc. You're right that it does require you to call their public interface dlls, but they're pretty ridiculously stable.
- LukeShu 8y ago
  Windows calls their syscall wrapper ntdll.dll, not libc.so; but it's conceptually the same thing. The ntdll.dll ABI is public & stable, the underlying syscall ABI isn't. Several unixoids do the same thing, where their libc.so ABI is public & stable, but the underlying syscall ABI isn't.
giovannibajo1 8y ago
This is not related to syscall vs libc. OpenBSD 6.4 requires stacks to be mapped with MAP_STACK, so it requires a runtime change. I’m not sure how using libc would have prevented this Ref: https://github.com/golang/go/issues/26142 https://github.com/golang/go/issues/26142

by ptx 8y ago

LukeShu 8y ago

OpenBSD doesn't make any promises about ABI stability between releases. That means that all older binaries may stop working when you upgrade the OS, not just older Go binaries.

zdw 8y ago
This might be seen as a problem, but it allows the OpenBSD devs to push the envelope of expectations and find bugs across the entire software ecosystem. An example of this was the change to 64-bit time_t back in 2013 (talk: https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ ), and evolving syscalls like pledge(2) that changed syntax between releases as the problems/benefits of a specific implementation choices were learned.

AnIdiotOnTheNet 8y ago

> Many operating systems, including Windows, don't consider that a stable public interface. Windows in no way requires libc. You're right that it does require you to call their public interface dlls, but they're pretty ridiculously stable.

LukeShu 8y ago
Windows calls their syscall wrapper ntdll.dll, not libc.so; but it's conceptually the same thing. The ntdll.dll ABI is public & stable, the underlying syscall ABI isn't. Several unixoids do the same thing, where their libc.so ABI is public & stable, but the underlying syscall ABI isn't.

giovannibajo1 8y ago

This is not related to syscall vs libc. OpenBSD 6.4 requires stacks to be mapped with MAP_STACK, so it requires a runtime change. I’m not sure how using libc would have prevented this Ref: https://github.com/golang/go/issues/26142 https://github.com/golang/go/issues/26142