From owner-freebsd-arch Thu Oct 25 18: 3:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id CF19837B403 for ; Thu, 25 Oct 2001 18:03:32 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.6/8.11.6) with ESMTP id f9Q13UE45171; Thu, 25 Oct 2001 19:03:30 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200110260103.f9Q13UE45171@hunkular.glarp.com> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Thu, 25 Oct 2001 16:36:02 PDT." <20011025233602.587C63808@overcee.netplex.com.au> Date: Thu, 25 Oct 2001 19:03:30 -0600 From: Brad Huntting Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > sizeof(time_t) exposed: > /etc/pwd.db (pw_change, pw_expire) > /var/run/utmp (ut_time) > /var/log/lastlog (ll_time) > /var/db/acct (ac_btime - begin time of a process) These files are rarely, if ever seen by other machines, so it would be easy enough to either convert, delete, or recreate them at upgrade time. > dump/restore tape format (spcl. c_data, d_ddate, etc) This should probably change hand in hand with ufs. > notable exceptions where times are explicitly sized: > ufs inode format (has ufs_time_t == 32 bits explicitly) Upgrading ufs and dump/restore to "big time" can be independent of other FreeBSD "big time" issues. After all, ufs has other size limitations, most notably ino_t which will begin biting long before 2038. > nfs (uses 32 bit timestamps in v3, and 64 bit on v4 (I believe)). This is something we cant change without forsaking interoperability, so let's not worry about it. > notable exceptions where times are *ambiguous*: > rpc on-the-wire (both int, u_int, long and u_long timestamps (!)) > yp/nis (uses u_long ctime, mtime - see struct nis_oid) Like nfs, we may need to corrupt time_t to 32 bits for some of these to maintain interoperability, but we cant expect to change established Internet protocols before upgrading to 64 bit time_t. > So.. What do people think? Let the bikeshedding begin... I dont see that switching all platforms to 64 bit time_t is that big a deal. Is time_t really that much more trouble than off_t? brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message