Date: Thu, 3 Dec 2020 12:05:04 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: <X8i4UIzzH7vxkKvH@kib.kiev.ua> In-Reply-To: <202012030523.0B35NsG7003810@slippy.cwsent.com> References: <202012030523.0B35NsG7003810@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 02, 2020 at 09:23:54PM -0800, Cy Schubert wrote: > An NTP developer at approached me about the prospect of a system call to > add or subtract time from the system clock, returning the current time > after the update. The two options were: > > 1. A new syscall, similar to clock_settime() and clock_gettime() that > adds/subtracts the delta, in a struct timespec, via a call to > kern_clock_settime(). Then atomically returns the current time as if > clock_gettime() was immediately called. > > 2. His colleague didn't think this was appropriate for their needs. He > wants a FreeBSD implementation of the Linux adjtimex() syscall. > > Though non-standard option 1 is least intrusive on existing applications. > > Option 2, implement the Linux adjtimex(): > > 1. The Linux adjtimex() appears to be a re-implementation of ntp_adjtime() > with the addition of ADJ_SETOFFSET. > > 2. ADJ_SETOFFSET adds or subtracts the time specified in a struct timeval > within the timex struct. Unfortunately the FreeBSD timex struct contains no > timeval. To implement this would require versioned symbols to maintain > backward compatiblity. There are two options, as far as I see: 1. Implement new syscall, which would take extended struct timex. ntp_adjtimex() perhaps should be kept for backward compatibility. [It does not matter where struct timeval is placed in the updated struct timex, see below]. 2. Extend existing struct timex with struct timeval at the end of the structure, but do not require it for any mode except when ADJ_SETOFFSET is specified in modes. In other words, syscall should copyin legacy struct timex, and if ADJ_SETOFFSET is set, copying struct timeval from the address right after timex. IMO option 1 is relatively simple and low overhead. Option 2 is just more work for a little gain. If you go the route 1, please add some padding at the end of extended struct timex so potential future modifications do not require a new syscall. Add me to the review anyway. NB. compat32 for ntp_adjtime(2) seems to be completely broken. It is probably a good moment to fix old syscall, since you would need to implement compat32 shims for the new one anyway. > > Up for discussion is: > > 1. Are we, FreeBSD, interested in implementing the Linux adjtimex() > syscall? (I would take on the task to author it should we feel this is a > worthwhile project. OTOH I prefer not to spend the time working on this if > the community feels otherwise.) > > 2. From a cursory scan through the tree it appears that ntp is the only > internal consumer of struct timex. There are probably others in ports and > other third party software such as openntpd and chrony. A versioned symbol > should satisfy old applications which might use the previous timex struct. > > Are we interested in the Linux adjtimex(2) for FreeBSD? > > > -- > Cheers, > Cy Schubert <Cy.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org > NTP: <cy@nwtime.org> Web: https://nwtime.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X8i4UIzzH7vxkKvH>