Date: Thu, 03 Dec 2020 10:17:51 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: <60532.1606990671@critter.freebsd.dk> In-Reply-To: <X8i4UIzzH7vxkKvH@kib.kiev.ua> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <X8i4UIzzH7vxkKvH@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- Konstantin Belousov writes: > 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]. That would break all ports with timekeeping software. Given the role of keeping the system-clock wrangled is single-user and not something you would normally run with old-version software, the simplest solution *if* we want to do this, is to simply extend struct timex for 13-R. BTW: Does anybody know what (is supposed to) happens of ADJ_SETOFFSET is active with other modes in struct timex, in particular MODE_OFFSET ? Is there a document describing how that is supposed to work ? > Add me to the review anyway. Me to. > NB. compat32 for ntp_adjtime(2) seems to be completely broken. It is pr= obabl > y > a good moment to fix old syscall, since you would need to implement comp= at32 > shims for the new one anyway. As per above: Compat'ing this syscall makes very little sense in practice= . -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?60532.1606990671>