On Sun, Aug 5, 2018 at 6:46 PM Bruce Evans <b...@optusnet.com.au> 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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
