On 24-02-13 08:17:20, Theo de Raadt wrote: > Stuart Henderson <s...@spacehopper.org> wrote: > > > On 2024/02/13 07:36, Theo de Raadt wrote: > > > Stuart Henderson <stu.li...@spacehopper.org> wrote: > > > > > > > On 2024-02-13, Kirill A Korinsky <kir...@korins.ky> wrote: > > > > > Good day, > > > > > > > > > > I'm updating go's syscall table to modern OpenBSD (7.4). > > > > > > > > Save your time. Post-7.4 you cannot call syscall() any more. > > > > > > The result seems to have nothing to do with syscalls. > > > > > > It is the same as the build process for kdump: It is finding cpp > > > definitions > > > most of which are argument flags, but also a few structs in /usr/include, > > > and > > > making them available at some level inside the go ecosystem. So if in go > > > you > > > call a system call via the regular stub API, you may need those flags. > > > you may > > > also need them for some other higher-level function call? go doesn't pull > > > from /usr/include otherwise, does it? > > > > > > > > > > Oh, yes those are still needed then, I'd forgotten they were part of the > > same thing from last time I tried to get them updated ... > > there probably needs to be a formal process to update at least once a year, > or just before a release, and also upstream.
The operating system specific parts of the Go syscall package are effectively deprecated/frozen (and have been for nearly 10 years, hence not being updated): https://pkg.go.dev/syscall https://go.googlesource.com/proposal/+/refs/heads/master/design/freeze-syscall.md On the other hand, golang.org/x/sys/unix is maintained and updated semi-regularly: https://pkg.go.dev/golang.org/x/sys/unix With the exception of the OpenBSD syscall numbers: https://cs.opensource.google/go/x/sys/+/master:unix/zsysnum_openbsd_amd64.go;l=8
