Date: Mon, 03 Feb 2003 22:35:05 +0100 From: phk@freebsd.org To: John Baldwin <jhb@freebsd.org> Cc: cvs-all@freebsd.org, cvs-committers@freebsd.org Subject: Re: cvs commit: src/sys/fs/msdosfs msdosfs_conv.c src/sys/fs/nwf Message-ID: <13075.1044308105@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 03 Feb 2003 16:23:20 EST." <XFMail.20030203162320.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <XFMail.20030203162320.jhb@FreeBSD.org>, John Baldwin writes: > >> Modified files: >> sys/fs/msdosfs msdosfs_conv.c >> sys/fs/nwfs nwfs_subr.c >> sys/fs/smbfs smbfs_subr.c >> sys/i386/ibcs2 ibcs2_xenix.c >> sys/i386/isa clock.c >> sys/kern kern_time.c subr_clock.c >> sys/pc98/pc98 clock.c >> sys/sys kernel.h >> Log: >> Split the global timezone structure into two integer fields to >> prevent the compiler from optimizing assignments into byte-copy >> operations which might make access to the individual fields non-atomic. >> >> Use the individual fields throughout, and don't bother locking them with >> Giant: it is no longer needed. > >Umm, what's to prevent, say, a sparc64 CPU from being interrupted >in between the load, modify, and store instructions? There are no load modify and store instructions. Three are reads and there are writes. One of the two fields is only ever used to report back to userland, and userland wisely ignores it, because it has not had any practical significance or meaning for the last ten years. The other field is (mis-)used by certain filesystems which store timestamps in localtime rather than UTC time. This is a problem in its own right: These filesystems are subject to a major race from when DST starts/stops until some userland program comes around and informs the kernel about the new UTC offset. This issue also beggs the question: If the timestamp on the media is "localtime", is it then the localtime where the server is located (Hoople, N. Dakota) or where the user is located (Mud, Elbonia), and when the user causes a timestamp to be updated, which of the two localtimes is it that is used for the update ? The close to ideal solution for these filesystems would be for stat/fstat to have a flag saying "timestamps are in localtime" and have the wrapper in libc convert to proper UTC timestamps when that flag comes out of the kernel. Unfortunately, on the way back into the kernel the problem is much harder to solve in a meaningful way, unless we start passing a localtime timestamp into the kernel for a lot of file operations, including write(2). And no, I'm not even going to think about this problem longer than it will take me to say: Microsoft really screwed this one up... -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13075.1044308105>