From owner-svn-src-all@freebsd.org Mon Feb 12 18:55:56 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C650F122E0 for ; Mon, 12 Feb 2018 18:55:56 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DBE185DF1 for ; Mon, 12 Feb 2018 18:55:55 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 522c08cc-1026-11e8-bb8e-b35b57339d60 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 522c08cc-1026-11e8-bb8e-b35b57339d60; Mon, 12 Feb 2018 18:55:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1CItrpS035306; Mon, 12 Feb 2018 11:55:53 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1518461752.94819.42.camel@freebsd.org> Subject: Re: svn commit: r329173 - head/sys/kern From: Ian Lepore To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Mon, 12 Feb 2018 11:55:52 -0700 In-Reply-To: <201802121741.w1CHfBWa069971@repo.freebsd.org> References: <201802121741.w1CHfBWa069971@repo.freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 18:55:56 -0000 On Mon, 2018-02-12 at 17:41 +0000, Ian Lepore wrote: > Author: ian > Date: Mon Feb 12 17:41:11 2018 > New Revision: 329173 > URL: https://svnweb.freebsd.org/changeset/base/329173 > > Log: >   Add a new sysctl, debug.clock_do_io, to allow manully triggering a one-shot >   read or write of all registered realtime clocks.  In the read case, the >   values read are simply discarded.  For writes, there's no alternative but >   to actually write the current system time to the device. > > Modified: >   head/sys/kern/subr_rtc.c I've received several questions about this series of commits, which I think means I probably should have put it up for review first.  I didn't do so only because every other RTC-related change I've put on phab has just languished without comments for a couple weeks before I gave up waiting and committed it anyway. As to what this series of rtc debugging changes was about in general... I'm tired of hacking read-now/write-now sysctls into (and then back out of before committing) every RTC driver I've ever worked on.  It's nice to be able to debug them without actually changing the time on the system continuously and/or rebooting.  If you can trigger the IO on demand you can use kldload/unload while testing.  Otherwise the only way to make a read happen after you've made a code change is to reboot.   Another motivation: I want to eliminate atrtc's ddb "show rtc" command that only works in that one of the dozen+ rtc drivers we have, and it brings complications to the atrtc code that I want to clean up.   As to why I made clock_do_io a "write to read" thing... I find myself always doing "sysctl -a | grep something" where something is some fragment of an oid name I vaguely remember.  I'm probably not alone in doing things like that, and I didn't want sysctl -a to start triggering expensive hardware accesses like i2c bus transactions; that's why I made it "write-to-read" (which requires that you go look for the debugging output on the console or in dmesg, which is klunky, but hey... this is debugging stuff, not some fancy new kernel abi for reading time). -- Ian