From owner-freebsd-arch@freebsd.org Fri Dec 11 15:15:40 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4F8A84B1D7A for ; Fri, 11 Dec 2020 15:15:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CsvVg1QVHz4SYk; Fri, 11 Dec 2020 15:15:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0BBFFOIb019161 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 11 Dec 2020 17:15:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0BBFFOIb019161 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0BBFFNJu019123; Fri, 11 Dec 2020 17:15:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 Dec 2020 17:15:23 +0200 From: Konstantin Belousov To: Cy Schubert Cc: Poul-Henning Kamp , Ian Lepore , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> <202012032203.0B3M3VJx004269@slippy.cwsent.com> <25989.1607033614@critter.freebsd.dk> <202012032258.0B3MwqVQ004875@slippy.cwsent.com> <202012040114.0B41EuFc006408@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202012040114.0B41EuFc006408@slippy.cwsent.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CsvVg1QVHz4SYk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.75 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.75)[0.749]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 15:15:40 -0000 On Thu, Dec 03, 2020 at 05:14:56PM -0800, Cy Schubert wrote: > In message , Konstantin Belousov writes: > > On Thu, Dec 03, 2020 at 02:58:52PM -0800, Cy Schubert wrote: > > > In message <25989.1607033614@critter.freebsd.dk>, "Poul-Henning Kamp" > > > writes: > > > > -------- > > > > Cy Schubert writes: > > > > > > > > > I will go back > > > > > with my initial proposal of a timespec add/subtract syscall takes a > > > > > timespec as input increments or decrements the clock by the timespec an > > d > > > > > returns a timespec with the time. > > > > > > > > I would be tempted by the clock_settime(2) "clock_id" argument. > > > > > > > > The functionality required has a LOT more commonality with > > > > clock_settime(2) than with ntp_adjtime(2), and absconding with a > > > > couple of the top bits of clock_id for "CLOCK_ADD_ADJUSTMENT" and > > > > "CLOCK_SUB_ADJUSTMENT" would be be a pretty clean solution. > > > > > > Correct. My initial proposal was: > > > > > > +.Fn clock_updtime "clockid_t clock_id" "const struct timespec *itp" > > > "struct timespec *otp" > > > > > > Briefly it does this: > > > > > > +int > > > +kern_clock_updtime(struct thread *td, clockid_t clock_id, > > > + const struct timespec *its, struct timespec *ots) > > Note that phk suggested using specific clock id with clock_settime(), > > and I believe that you only need one such clock id. > > Correct. This is from work I stashed in my git repo from Sunday. I haven't > updated it yet with phk's suggestions. > > > > > > +{ > > > + struct timespec ats; > > > + int error; > > > + > > > + if ((error = kern_clock_gettime(td, clock_id, &ats)) != 0) > > > + return (error); > > > + > > > + timespecadd(its, &ats, &ats); > > > + > > > + if ((error = kern_clock_settime(td, clock_id, &ats)) != 0) > > > + return (error); > > > + > > > + return(kern_clock_gettime(td, clock_id, ots)); > > > +} > > This is awful, it must not be done this way. > > > > Look how tc_setclock() is implemented. It is careful to adjust time > > with interrupts and preemption disabled, and does it by adjusting the > > source of truth, not by fetching through several layers and then hoping > > that we did not get delayed too much when pushing back. > > Thanks. I'll look there. > > > > > I think you need to refactor tc_setclock() somewhat to allow to specify > > offset instead of absolute value and use it as a helper. > > I'll do that. I'll add phk and you as reviewers. > > > > > > > > > I can prepare a review if you want. I haven't touched the man page nor any > > > tests yet. > > > > > > It's affected by kib@'s https://reviews.freebsd.org/D27471, as conflicts > > > will result. I'll wait until that's committed before continuing work on it, > > > > > assuming this is the direction we want to go. > > This change does not affect *setclock() work above. > > Thanks. Ok, I went ahead and wrote https://reviews.freebsd.org/D27571 . This should handle all notes from the conversation.