From owner-svn-src-head@freebsd.org Wed Nov 14 00:53:16 2018 Return-Path: Delivered-To: svn-src-head@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 A54A61102C69 for ; Wed, 14 Nov 2018 00:53:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3B2484398 for ; Wed, 14 Nov 2018 00:53:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it1-x130.google.com with SMTP id k206-v6so21396910ite.0 for ; Tue, 13 Nov 2018 16:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5JR8y7AUBGAkFSJ4dR4cQUyI5p43bR8FQ53Ctz9vW/8=; b=w547Z751wbqE+8H0VzH7pU7cVDkreHmRh8sdJI+97Aa+rvVS4W4OqJh+4lAKT9XLEk s+Vgc/aZYLNoOvHt6Wf6DeFyI9rkLBkXFOyWIae8yJcOE2OyQ5T+Fu6HMO2WMBPs4ZiB HON0ZvXN1e0PKvx+Rdz3I8L4iMtuvnknwGlCN2cbNAVocTKJ14mWyVu646+4bdBKiDVI sG3Wcj//T3S1iayEI/nCa+hKm4mSuavKOLLF/cx16w1/yR6Pe/Enk7j5xXBJwZM2Wj8M nIIMS+SjZG0HeVO2Z99kgu1REFUL0qe0iV8vi6veLr6G35nxy6JuDWBZjl2KjYQ/uxbl wlRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5JR8y7AUBGAkFSJ4dR4cQUyI5p43bR8FQ53Ctz9vW/8=; b=QRlUILf838XTE/I2S//O8p1Q3B+s9ESRkaJ4FSyxKkZolSktCXuy6nJ0vaINWabCPH 2IttaepU6F+RynaASQPw1SF9RqTImhCDss9OxcEkkGa9j9xQI+PGyExhbMMBUcIq6Rdd rNyBTD83jYOgLvse3XKUdvve0kbYX+zbHuuTZrSdHkIWfH/Niw+lvVg9hVEC2UUvg6Dt 2653FeetbFexfIVO6hYTA1oiBw57otUna0vxt9z8rP7oGiGMhvBNSWUDJFXKPQ5hJN58 TLzhtcKF5vk2zPiiLfqxZmO3u2XWJ3aYEUcTWx3o3V7nvSfnpYzChA87z4NgEfuzdjjD lyCA== X-Gm-Message-State: AGRZ1gJWZEShbpBZEiGyJfVLtcklWVSruau0tF8fiPo89jewDu/BuqEp i8H6NNqVpTlvZp9m1AH0E5AByYaibAanwAZsgZlV+A== X-Google-Smtp-Source: AJdET5ejjynyd9puBwajBUOl/CmnSBV2NH1zMHvWVes+h0+ykEthNjGTqjbZ29QkBtqYJQGnruxsG2bjoaA65pWiHqU= X-Received: by 2002:a02:31d:: with SMTP id y29-v6mr6921364jad.98.1542156794846; Tue, 13 Nov 2018 16:53:14 -0800 (PST) MIME-Version: 1.0 References: <201808042208.w74M8OmD057603@repo.freebsd.org> <201808042224.w74MOgLi095274@pdx.rh.CN85.dnsmgr.net> <1533478958.9860.18.camel@freebsd.org> <20180806074507.E920@besplex.bde.org> <20180806095604.J860@besplex.bde.org> In-Reply-To: <20180806095604.J860@besplex.bde.org> From: Warner Losh Date: Tue, 13 Nov 2018 17:53:04 -0700 Message-ID: Subject: Re: svn commit: r337334 - head/lib/libc/sys To: Bruce Evans Cc: Ian Lepore , "Rodney W. Grimes" , "Conrad E. Meyer" , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: D3B2484398 X-Spamd-Result: default: False [-5.48 / 200.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[0.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[optusnet.com.au]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.49)[ip: (-7.71), ipnet: 2607:f8b0::/32(-2.77), asn: 15169(-1.86), country: US(-0.09)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 00:53:16 -0000 On Sun, Aug 5, 2018 at 6:46 PM Bruce Evans wrote: > On Mon, 6 Aug 2018, Bruce Evans wrote: > > > ... > > I forgot about FAT times, and only remembered that utc_offset() was used > > for RTC drivers. I thought that utc_offset() is 0 unless something sets > > the timezone to nonzero or the RTC is on local time (wall_cmos_clock > case). > > However, since the kernel needs the timezone for FAT times, it must be > > known even if the RTC is on UTC time. Now I don't see how FAT times can > > even work unless the wall_cmos_clock. They are just the UTC minus > > utc_offset(), where utc_offset() is > > > > (tz_minuteswest * 60 + (wall_cmos_clock ? adjkerntz : 0)) > > > > Here wall_cmos_clock is only for managing the RTC offset. It must be 0 > > unless the RTC is on local time. But then either FAT times or RTC times > > must be broken except in the Greenwich meridian. Otherwise, > tz_minuteswest > > must be nonzero to ajust FAT times right, but this makes utc_offset() > > unusable for the RTC offset. > > I verified the brokenness: > - adjkerntz() normally leaves tz_minuteswest as 0. I verified that it does > this when there is a nonzero dst adjustment. dst adjustments are folded > into machdep.adjkerntz. > Right. adjkerntz() was supposed to completely replace tz_minuteswest. > - when wall_cmos_clock == 0, adjkerntz(8) does little or nothing, so all > adjustments are 0, so utc_offset() is 0, so FAT times are broken except > in the Greenwich meridian. > > The broken FAT times are not completely obvious, since getting and setting > them use the same wrong offset of 0, so the times appear to be correct when > displayed on FreeBSD. The are only obviously wrong when displayed on > another > system with non-broken FAT times, perhaps by rebooting to the other system > or by moving removable media to such a system. > > FAT times are used by other file systems. I checked this in FreeBSD-9 > so as to find axed file systems. The were used by smbfs, nwfs and msdosfs. > Now they are only used by msdosfs. I never liked de-deduplicating their > implementation into an over-engineered version with especially excessive > handling for leap years. Leap year handling is unimportant compared with > offset handling. > And tz_minuteswest won't fix this, except on a single user system. And it is duplicative of adjkerntz. > tz_minuteswest is used by compatibility code. It cannot usefully be > removed from the native version, since non-native syscalls use it and > non-native applications might use it. Of course, it must have a correct > value to work in compatibility. Its normal value of 0 breaks compatibility > code much like the bugs in utc_offset() breaks FAT time. It is used in the > following compatibility code: > - amd64 linux32 linux_gettimeofday(). Like native gettimeofday(). It also > reconstructs the dstflag part of the timezone struct. If linux drops > this, > then strict compatiility requires the support to depend on the linux > version. > - amd64 linux32 linux_settimeofday(). Like native settimeofday(). Has > invisible reference to tz_minuteswest hidden in assignment of timezones. > I only grepped for tz_minuteswest and only checked this indirect > reference. > - freebsd32 freebsd32_gettimeofday(). Similarly, except we control it, so > can avoid needing version checks by not dropping support. > - dev/tws/tws_services.h. This uses utc_offset() for FreeBSD-7 and later, > and its reference to tz_minuteswest is only explicit for older versions > where it open-codes utc_offset() with bug for bug compatibility except > for > adding style bugs. > - smbfs. This uses FAT times, and in nearby code it uses tzoff for the > offset > and has commented-out code with an open-coded fully-buggy utc_offset(). > - ibcs2 xenix_ftime(). This is similar to gettimeofday(). > All of these are somewhat irrelevant. If anybody really cares about these cases, they can fix them to use the adjkerntz() facility (or in the case of tws, just remove the bogus code). The question is, does anybody use this feature? It's been obsolete for 2 decades and we should just remove it. Warner