The time/lib/ntpshm package writes samples to the ntpd/NTPsec SHM refclock, but only on Linux and macOS. On Windows it falls back to shm_stub.go, whose newShmWriter returns ErrUnsupported, so a configured [ntp.shm] segment fails to attach. ntpd itself supports SHM on Windows, so a Windows-native writer would bring the daemon up to the macOS feature set.
The change is contained to time/lib/ntpshm: reimplement the attach mechanism against Win32 named file mappings (the approach ntpd's refclock_shm.c uses under SYS_WINNT) instead of SysV shared memory. The shmTime struct layout is byte-identical on windows/amd64, so only attach/detach differ; the daemon wiring is unchanged.
Depends on the Windows compile port. Related to #338 (the SHM writer is part of the feature set the Windows service assumes, but independent of the service integration and can land separately).
See plan/windows-shm.md.
The
time/lib/ntpshmpackage writes samples to the ntpd/NTPsec SHM refclock, but only on Linux and macOS. On Windows it falls back toshm_stub.go, whosenewShmWriterreturnsErrUnsupported, so a configured[ntp.shm]segment fails to attach. ntpd itself supports SHM on Windows, so a Windows-native writer would bring the daemon up to the macOS feature set.The change is contained to
time/lib/ntpshm: reimplement the attach mechanism against Win32 named file mappings (the approach ntpd'srefclock_shm.cuses underSYS_WINNT) instead of SysV shared memory. TheshmTimestruct layout is byte-identical on windows/amd64, so only attach/detach differ; the daemon wiring is unchanged.Depends on the Windows compile port. Related to #338 (the SHM writer is part of the feature set the Windows service assumes, but independent of the service integration and can land separately).
See
plan/windows-shm.md.