From owner-freebsd-standards@FreeBSD.ORG Sun Oct 12 13:10:28 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56C2C16A4B3 for ; Sun, 12 Oct 2003 13:10:28 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F7A43FDD for ; Sun, 12 Oct 2003 13:10:24 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9CKAOFY030321 for ; Sun, 12 Oct 2003 13:10:24 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9CKAOdn030320; Sun, 12 Oct 2003 13:10:24 -0700 (PDT) (envelope-from gnats) Resent-Date: Sun, 12 Oct 2003 13:10:24 -0700 (PDT) Resent-Message-Id: <200310122010.h9CKAOdn030320@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "David Gardner" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 563E416A4B3 for ; Sun, 12 Oct 2003 13:03:10 -0700 (PDT) Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA26243F85 for ; Sun, 12 Oct 2003 13:03:09 -0700 (PDT) (envelope-from david@pinko.net) Received: from user-11204r7.dsl.mindspring.com ([66.32.19.103] helo=eden) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1A8mQk-0007hI-00 for FreeBSD-gnats-submit@freebsd.org; Sun, 12 Oct 2003 13:03:06 -0700 Message-Id: 1065989051@eden Date: Sun, 12 Oct 2003 13:04:12 -0700 From: "David Gardner" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: gtk-send-pr 0.1 Subject: standards/57911: fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) returns FNM_NOMATCH X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 20:10:28 -0000 >Number: 57911 >Category: standards >Synopsis: fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) returns FNM_NOMATCH >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Oct 12 13:10:23 PDT 2003 >Closed-Date: >Last-Modified: >Originator: David Gardner >Release: FreeBSD 4.8-RELEASE i386 >Organization: na >Environment: System: FreeBSD eden 4.8-RELEASE FreeBSD 4.8-RELEASE #3: Thu Jun i386 >From fnmatch.h: src/include/fnmatch.h,v 1.9 1999/11/21 17:32:45 fnmatch.h 8.1 (Berkeley) 6/2/93 g++ version 2.95.4 gcc version 3.0.4 >Description: The fnmatch function doesn't seem to like any of the character classes that are listed in the re_format man page. I ssh'ed to a linux box to check this and the character classes behaved the way I expected them to. >How-To-Repeat: #include #include void main () { int result = fnmatch ("[[:alpha:]]","x", FNM_PATHNAME); if (result == FNM_NOMATCH) cout << "failed" << endl; else cout << "passed" << endl; } >Fix: fnmatch seems to like the expression "[A-Za-z]" which is equivelent to "[[:alpha:]]". >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Mon Oct 13 06:42:02 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6227816A4B3; Mon, 13 Oct 2003 06:42:02 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6ACE43FBF; Mon, 13 Oct 2003 06:42:00 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9DDfx326736; Mon, 13 Oct 2003 15:41:59 +0200 (MEST) Date: Mon, 13 Oct 2003 15:41:59 +0200 (CEST) From: Harti Brandt To: standards@freebsd.org, sparc64@freebsd.org Message-ID: <20031013153219.H45269@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 13:42:02 -0000 Hi all, I just discovered that time_t is 32-bit on sparc64. One of the problems is that struct timeval is defined by Posix as struct timeval { time_t tv_secs; suseconds_t tv_usecs; }; but _timeval.h has struct timeval { long tv_secs; suseconds_t tv_usecs; } This means, that our timeval is not Posix compatible. What is the reason for time_t not beeing a long on sparc64? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Mon Oct 13 11:01:50 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9324D16A4B3 for ; Mon, 13 Oct 2003 11:01:50 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C42C243F85 for ; Mon, 13 Oct 2003 11:01:40 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9DI1eFY044429 for ; Mon, 13 Oct 2003 11:01:40 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9DI1d8h044423 for freebsd-standards@freebsd.org; Mon, 13 Oct 2003 11:01:39 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Oct 2003 11:01:39 -0700 (PDT) Message-Id: <200310131801.h9DI1d8h044423@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 18:01:50 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/01/23] misc/24590 standards timezone function not compatible witn Sin o [2002/02/25] bin/35307 standards standard include files are not standard c o [2003/03/05] bin/48958 standards The type 'bool' has different sizes for C o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/06/20] standards/53554standards interval timers not cleared in fork() o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2003/09/15] standards/56906standards Several math(3) functions fail to set err 8 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi o [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/18] standards/36076standards Implementation of POSIX fuser command o [2002/06/13] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] misc/40378 standards stdlib.h gives needless warnings with -an p [2002/07/16] standards/40669standards command command does not support `-p' opt p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/23] standards/46504standards Warnings in headers o [2003/04/22] standards/51292standards [PATCH] add ecvt()/fcvt()/gcvt() function o [2003/06/22] standards/53613standards FreeBSD doesn't define EPROTO o [2003/06/24] bin/53682 standards [PATCH] add fuser(1) utitity o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/24] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/09/04] standards/56476standards cd9660 unicode support simple hack o [2003/09/27] standards/57295standards [patch] make does not include cmd line va o [2003/10/12] standards/57911standards fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) 19 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Oct 13 11:04:06 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AE5816A4BF for ; Mon, 13 Oct 2003 11:04:06 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C40F84403B for ; Mon, 13 Oct 2003 11:03:16 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9DI3GFY046466 for ; Mon, 13 Oct 2003 11:03:16 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9DI3Ffo046460 for standards@freebsd.org; Mon, 13 Oct 2003 11:03:15 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Oct 2003 11:03:15 -0700 (PDT) Message-Id: <200310131803.h9DI3Ffo046460@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: standards@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 18:04:06 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/08/18] kern/29844 standards [PATCH] setpgrp does not behave as manual 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1995/01/11] i386/105 standards Distributed libm (msun) has non-standard o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2000/12/05] kern/23304 standards POSIX clock_gettime, clock_getres return s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public 4 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Oct 13 11:19:10 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 370E116A4B3; Mon, 13 Oct 2003 11:19:10 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22BED43F93; Mon, 13 Oct 2003 11:19:05 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id EAA09624; Tue, 14 Oct 2003 04:18:56 +1000 Date: Tue, 14 Oct 2003 04:17:34 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Harti Brandt In-Reply-To: <20031013153219.H45269@beagle.fokus.fraunhofer.de> Message-ID: <20031014035805.F32262@gamplex.bde.org> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 18:19:10 -0000 On Mon, 13 Oct 2003, Harti Brandt wrote: > I just discovered that time_t is 32-bit on sparc64. One of the problems > is that struct timeval is defined by Posix as > > struct timeval { > time_t tv_secs; > suseconds_t tv_usecs; > }; This is a bug in POSIX. In BSD, tv_secs has type long which may be, and is different from time_t. > but _timeval.h has > > struct timeval { > long tv_secs; > suseconds_t tv_usecs; > } > > This means, that our timeval is not Posix compatible. What is the reason > for time_t not beeing a long on sparc64? time_t was used in some data structures whose layout shouldn't be changed even for new arches. Mainly in ufs in Lite2: %%% ffs/fs.h: time_t fs_time; /* last time written */ ffs/fs.h: time_t cg_time; /* time last written */ ffs/fs.h: time_t cg_time; /* time last written */ lfs/lfs.h: time_t bi_segcreate; /* origin segment create time */ ufs/quota.h: time_t dqb_btime; /* time limit for excessive disk use */ ufs/quota.h: time_t dqb_itime; /* time limit for excessive files */ %%% These are now: %%% ffs/fs.h: int32_t fs_old_time; /* last time written */ ffs/fs.h: ufs_time_t fs_time; /* last time written */ ffs/fs.h: int32_t cg_old_time; /* time last written */ ffs/fs.h: ufs_time_t cg_time; /* time last written */ /dev/null: time_t bi_segcreate; /* origin segment create time */ ufs/quota.h: int32_t dqb_btime; /* time limit for excessive disk use */ ufs/quota.h: int32_t dqb_itime; /* time limit for excessive files */ %%% I.e., int32_t is now not mispelled time_t in f^Hufs1 and Y2.038K bugs are fixed in ffs2 except for quotas. ffs2 also parametrizes timestamps in inodes better: %%% ufs/dinode.h:typedef int64_t ufs_time_t; ufs/dinode.h: ufs_time_t di_atime; /* 32: Last access time. */ ufs/dinode.h: ufs_time_t di_mtime; /* 40: Last modified time. */ ufs/dinode.h: ufs_time_t di_ctime; /* 48: Last inode change time. */ ufs/dinode.h: ufs_time_t di_birthtime; /* 56: Inode creation time. */ ufs/dinode.h: int32_t di_mtimensec; /* 64: Last modified time. */ ufs/dinode.h: int32_t di_atimensec; /* 68: Last access time. */ ufs/dinode.h: int32_t di_ctimensec; /* 72: Last inode change time. */ ufs/dinode.h: int32_t di_birthnsec; /* 76: Inode creation time. */ [Note that these aren't in a timespec struct, POSIX or otherwise, since the struct would give MD packing which happens to be inefficient in most cases.] ufs/dinode.h: int32_t di_atime; /* 16: Last access time. */ ufs/dinode.h: int32_t di_atimensec; /* 20: Last access time. */ ufs/dinode.h: int32_t di_mtime; /* 24: Last modified time. */ ufs/dinode.h: int32_t di_mtimensec; /* 28: Last modified time. */ ufs/dinode.h: int32_t di_ctime; /* 32: Last inode change time. */ ufs/dinode.h: int32_t di_ctimensec; /* 36: Last inode change time. */ [Y2.038K bugs are still in ffs1.] %%% To change time_t to 64 bits, all in-use non-transient data structures need to be changed similarly. Bruce From owner-freebsd-standards@FreeBSD.ORG Tue Oct 14 01:39:15 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4357216A4B3; Tue, 14 Oct 2003 01:39:15 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 444A943FAF; Tue, 14 Oct 2003 01:39:13 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9E8d3303921; Tue, 14 Oct 2003 10:39:05 +0200 (MEST) Date: Tue, 14 Oct 2003 10:39:03 +0200 (CEST) From: Harti Brandt To: Bruce Evans In-Reply-To: <20031014035805.F32262@gamplex.bde.org> Message-ID: <20031014103446.U45269@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014035805.F32262@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 08:39:15 -0000 Thanks for this info Bruce, two questions however: On Tue, 14 Oct 2003, Bruce Evans wrote: BE>On Mon, 13 Oct 2003, Harti Brandt wrote: BE> BE>> I just discovered that time_t is 32-bit on sparc64. One of the problems BE>> is that struct timeval is defined by Posix as BE>> BE>> struct timeval { BE>> time_t tv_secs; BE>> suseconds_t tv_usecs; BE>> }; BE> BE>This is a bug in POSIX. In BSD, tv_secs has type long which may be, BE>and is different from time_t. Why do you think this is a POSIX bug? Aren't we the odd man out? Now we (and MacOS 10) require a workaround for thinks like printf("%s", ctime(tv.tv_secs)); which works perfect on other systems. BE> BE>> but _timeval.h has BE>> BE>> struct timeval { BE>> long tv_secs; BE>> suseconds_t tv_usecs; BE>> } BE>> BE>> This means, that our timeval is not Posix compatible. What is the reason BE>> for time_t not beeing a long on sparc64? BE> BE>time_t was used in some data structures whose layout shouldn't be changed BE>even for new arches. Mainly in ufs in Lite2: BE> BE>%%% BE>ffs/fs.h: time_t fs_time; /* last time written */ BE>ffs/fs.h: time_t cg_time; /* time last written */ BE>ffs/fs.h: time_t cg_time; /* time last written */ BE>lfs/lfs.h: time_t bi_segcreate; /* origin segment create time */ BE>ufs/quota.h: time_t dqb_btime; /* time limit for excessive disk use */ BE>ufs/quota.h: time_t dqb_itime; /* time limit for excessive files */ BE>%%% BE> BE>These are now: BE> BE>%%% BE>ffs/fs.h: int32_t fs_old_time; /* last time written */ BE>ffs/fs.h: ufs_time_t fs_time; /* last time written */ BE>ffs/fs.h: int32_t cg_old_time; /* time last written */ BE>ffs/fs.h: ufs_time_t cg_time; /* time last written */ BE>/dev/null: time_t bi_segcreate; /* origin segment create time */ BE>ufs/quota.h: int32_t dqb_btime; /* time limit for excessive disk use */ BE>ufs/quota.h: int32_t dqb_itime; /* time limit for excessive files */ BE>%%% BE> BE>I.e., int32_t is now not mispelled time_t in f^Hufs1 and Y2.038K bugs are BE>fixed in ffs2 except for quotas. BE> BE>ffs2 also parametrizes timestamps in inodes better: BE> BE>%%% BE>ufs/dinode.h:typedef int64_t ufs_time_t; BE>ufs/dinode.h: ufs_time_t di_atime; /* 32: Last access time. */ BE>ufs/dinode.h: ufs_time_t di_mtime; /* 40: Last modified time. */ BE>ufs/dinode.h: ufs_time_t di_ctime; /* 48: Last inode change time. */ BE>ufs/dinode.h: ufs_time_t di_birthtime; /* 56: Inode creation time. */ BE>ufs/dinode.h: int32_t di_mtimensec; /* 64: Last modified time. */ BE>ufs/dinode.h: int32_t di_atimensec; /* 68: Last access time. */ BE>ufs/dinode.h: int32_t di_ctimensec; /* 72: Last inode change time. */ BE>ufs/dinode.h: int32_t di_birthnsec; /* 76: Inode creation time. */ BE> BE>[Note that these aren't in a timespec struct, POSIX or otherwise, since the BE>struct would give MD packing which happens to be inefficient in most cases.] BE> BE>ufs/dinode.h: int32_t di_atime; /* 16: Last access time. */ BE>ufs/dinode.h: int32_t di_atimensec; /* 20: Last access time. */ BE>ufs/dinode.h: int32_t di_mtime; /* 24: Last modified time. */ BE>ufs/dinode.h: int32_t di_mtimensec; /* 28: Last modified time. */ BE>ufs/dinode.h: int32_t di_ctime; /* 32: Last inode change time. */ BE>ufs/dinode.h: int32_t di_ctimensec; /* 36: Last inode change time. */ BE> BE>[Y2.038K bugs are still in ffs1.] BE>%%% BE> BE>To change time_t to 64 bits, all in-use non-transient data structures BE>need to be changed similarly. I guess we have to do this work before 2038, don't we? If we don't do it before 5.2 we have to stick with this until 6.0. Correct? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Tue Oct 14 08:20:26 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB6F016A4B3; Tue, 14 Oct 2003 08:20:26 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E092D43F3F; Tue, 14 Oct 2003 08:20:24 -0700 (PDT) (envelope-from schilling@fokus.fraunhofer.de) Received: from burner.fokus.fraunhofer.de (burner [193.175.133.116]) h9EFKLD01393; Tue, 14 Oct 2003 17:20:21 +0200 (MEST) Received: (from jes@localhost)h9EFKCip004956; Tue, 14 Oct 2003 17:20:12 +0200 (CEST) Date: Tue, 14 Oct 2003 17:20:12 +0200 (CEST) From: Joerg Schilling Message-Id: <200310141520.h9EFKCip004956@burner.fokus.fraunhofer.de> To: bde@zeta.org.au, brandt@fokus.fraunhofer.de, schilling@fokus.fraunhofer.de, sparc64@freebsd.org, standards@freebsd.org Subject: Re: time_t on sparc64 (fwd) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 15:20:26 -0000 >---------- Forwarded message ---------- >Date: Tue, 14 Oct 2003 04:17:34 +1000 (EST) >From: Bruce Evans >To: Harti Brandt >Cc: standards@freebsd.org, sparc64@freebsd.org >Subject: Re: time_t on sparc64 >On Mon, 13 Oct 2003, Harti Brandt wrote: >> I just discovered that time_t is 32-bit on sparc64. One of the problems >> is that struct timeval is defined by Posix as >> >> struct timeval { >> time_t tv_secs; >> suseconds_t tv_usecs; >> }; >This is a bug in POSIX. In BSD, tv_secs has type long which may be, >and is different from time_t. No, it is definitely not a POSIX bug. POSIX is consistent and doesn't need to be fixed. FreeBSD is inconsistent. You cannot call e.g. ctime(&t.tv_sec) >> but _timeval.h has >> >> struct timeval { >> long tv_secs; >> suseconds_t tv_usecs; >> } >> >> This means, that our timeval is not Posix compatible. What is the reason >> for time_t not beeing a long on sparc64? >time_t was used in some data structures whose layout shouldn't be changed >even for new arches. Mainly in ufs in Lite2: >%%% >ffs/fs.h: time_t fs_time; /* last time written */ >ffs/fs.h: time_t cg_time; /* time last written */ This looks like an internal implementation problem of the FreeBSD kernel. This is definitely bejond the scope of a standard. Please note that introducing an inconsistent user interface is much harder to fix later than adding a few hacks into the kernel and fix the real kernel problem later. You have nearly 35 years left.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily From owner-freebsd-standards@FreeBSD.ORG Tue Oct 14 10:51:34 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D202D16A4BF for ; Tue, 14 Oct 2003 10:51:34 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1F1D43F93 for ; Tue, 14 Oct 2003 10:51:33 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.10/8.12.9) with ESMTP id h9EHpNF1015896; Tue, 14 Oct 2003 13:51:23 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031014103446.U45269@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014035805.F32262@gamplex.bde.org> <20031014103446.U45269@beagle.fokus.fraunhofer.de> Date: Tue, 14 Oct 2003 13:51:22 -0400 To: Harti Brandt , Bruce Evans From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: standards@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 17:51:34 -0000 At 10:39 AM +0200 10/14/03, Harti Brandt wrote: > I guess we have to do this work before 2038, don't we? If > we don't do it before 5.2 we have to stick with this until > 6.0. Correct? While the project has been taking a mighty long time to get to "5.x-stable", I do think we should make it to "6.x-stable" before 2038... I do wish we could go for 64-bit times. However, I do not agree that we can just keep tossing in major API changes to the 5.x branch. We will never get to 5.x-stable if we constantly add major API changes to the 5.x branch. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-standards@FreeBSD.ORG Tue Oct 14 12:29:48 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABD5116A4B3; Tue, 14 Oct 2003 12:29:48 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 999DC43FBD; Tue, 14 Oct 2003 12:29:45 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id FAA16237; Wed, 15 Oct 2003 05:29:29 +1000 Date: Wed, 15 Oct 2003 05:28:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Harti Brandt In-Reply-To: <20031014103446.U45269@beagle.fokus.fraunhofer.de> Message-ID: <20031015045429.Q41837@gamplex.bde.org> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@FreeBSD.org cc: sparc64@FreeBSD.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 19:29:48 -0000 On Tue, 14 Oct 2003, Harti Brandt wrote: > On Tue, 14 Oct 2003, Bruce Evans wrote: > > BE>On Mon, 13 Oct 2003, Harti Brandt wrote: > BE> > BE>> I just discovered that time_t is 32-bit on sparc64. One of the problems > BE>> is that struct timeval is defined by Posix as > BE>> > BE>> struct timeval { > BE>> time_t tv_secs; > BE>> suseconds_t tv_usecs; > BE>> }; > BE> > BE>This is a bug in POSIX. In BSD, tv_secs has type long which may be, > BE>and is different from time_t. > > Why do you think this is a POSIX bug? Aren't we the odd man out? Now we AFAIK (not all that far), timevals (or at least most of the things POSIX uses them for) are BSD things, so POSIX is broken since it is incompatable with the a reference implementation if not _the_ reference implementation. POSIX uses timevals mainly for getrusage(), select(), itimers, get/settimeofday(), utimes() and struct utmpx. All of these except utmpx are documented in the FreeBSD man pages ias first appearing in 4.2BSD. FreeBSD doesn't even have struct utmpx. It has struct utmp, which is documented as first appearing in V6. It is not quite compatible with V6 here and has actually regressed with respect to storing times: it uses "int32_t ut_time", but V7 uses "long ut_time". This regression occurred for binary compatibility reasons in FreeBSD (Lite2 uses "long ut_time"). > (and MacOS 10) require a workaround for thinks like > > printf("%s", ctime(tv.tv_secs)); & > > which works perfect on other systems. > BE>[ffs changes] > BE>To change time_t to 64 bits, all in-use non-transient data structures > BE>need to be changed similarly. > > I guess we have to do this work before 2038, don't we? If we don't do it > before 5.2 we have to stick with this until 6.0. Correct? Yes. It is too late to change it for 5.n IMO. Every syscall that uses a time_t or a timeval would need to be duplicated. This would give a lot of compatibility cruft that would have to be supported forever if the transition is not carefully managed. We still haven't managed to drop cruft like olseek() (to support 32-bit off_t's) although the clean break in 4.4BSD should have made it unnecessary. Bruce From owner-freebsd-standards@FreeBSD.ORG Tue Oct 14 15:51:29 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C396716A4D9; Tue, 14 Oct 2003 15:51:29 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F0A043FFD; Tue, 14 Oct 2003 15:51:08 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h9EMosbe094662; Tue, 14 Oct 2003 15:50:54 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) h9EMornb059137; Tue, 14 Oct 2003 15:50:53 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id h9EMorZV059136; Tue, 14 Oct 2003 15:50:53 -0700 (PDT) (envelope-from marcel) Date: Tue, 14 Oct 2003 15:50:53 -0700 From: Marcel Moolenaar To: Bruce Evans Message-ID: <20031014225053.GA59096@dhcp01.pn.xcllnt.net> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031015045429.Q41837@gamplex.bde.org> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 22:51:30 -0000 On Wed, Oct 15, 2003 at 05:28:08AM +1000, Bruce Evans wrote: > > > > I guess we have to do this work before 2038, don't we? If we don't do it > > before 5.2 we have to stick with this until 6.0. Correct? > > Yes. > > It is too late to change it for 5.n IMO. Every syscall that uses a time_t > or a timeval would need to be duplicated. I'd rather we create a new sysent and prune the syscalls to get rid of other compatibility cruft. It also allows us change userland visible structures to make them more LP64 friendly. BTW: time_t on ia64 is already 64 bit. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 00:06:50 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E5616A4B3; Wed, 15 Oct 2003 00:06:50 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221F843FAF; Wed, 15 Oct 2003 00:06:46 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9F76cD05857; Wed, 15 Oct 2003 09:06:38 +0200 (MEST) Date: Wed, 15 Oct 2003 09:06:38 +0200 (CEST) From: Harti Brandt To: Marcel Moolenaar In-Reply-To: <20031014225053.GA59096@dhcp01.pn.xcllnt.net> Message-ID: <20031015090422.M57857@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 07:06:50 -0000 On Tue, 14 Oct 2003, Marcel Moolenaar wrote: MM>On Wed, Oct 15, 2003 at 05:28:08AM +1000, Bruce Evans wrote: MM>> > MM>> > I guess we have to do this work before 2038, don't we? If we don't do it MM>> > before 5.2 we have to stick with this until 6.0. Correct? MM>> MM>> Yes. MM>> MM>> It is too late to change it for 5.n IMO. Every syscall that uses a time_t MM>> or a timeval would need to be duplicated. MM> MM>I'd rather we create a new sysent and prune the syscalls to get rid of MM>other compatibility cruft. It also allows us change userland visible MM>structures to make them more LP64 friendly. MM> MM>BTW: time_t on ia64 is already 64 bit. Hmm. In this case it should be rather easy to change sparc64's time_t to 64bit? The only changes should be in MD code (in theory). But this would clearly break existing installations, so I guess we'd rather wait until the fork of 6. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 00:44:56 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD8A16A4B3; Wed, 15 Oct 2003 00:44:56 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4104543FDD; Wed, 15 Oct 2003 00:44:55 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h9F7ikbe096983; Wed, 15 Oct 2003 00:44:46 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) h9F7iknb060405; Wed, 15 Oct 2003 00:44:46 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id h9F7ibPn060404; Wed, 15 Oct 2003 00:44:37 -0700 (PDT) (envelope-from marcel) Date: Wed, 15 Oct 2003 00:44:37 -0700 From: Marcel Moolenaar To: Harti Brandt Message-ID: <20031015074437.GA60338@dhcp01.pn.xcllnt.net> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031015090422.M57857@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 07:44:57 -0000 On Wed, Oct 15, 2003 at 09:06:38AM +0200, Harti Brandt wrote: > MM> > MM>BTW: time_t on ia64 is already 64 bit. > > Hmm. In this case it should be rather easy to change sparc64's time_t to > 64bit? Yes. The MI code is already done and there's not much MD code that is expected to break. It's mostly the structures that change. This is especially painful on sparc64 because it's big-endian. I assume that sparc64 passes syscall arguments in registers, so the syscalls that take a time_t do not change except that there's no sign extension prior to use. You can preserve the ABI until 2038 by ignoring the upper 32-bits in that case. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 00:51:16 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B01A216A4B3; Wed, 15 Oct 2003 00:51:16 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8583543FBF; Wed, 15 Oct 2003 00:51:14 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id EC88B66E5A; Wed, 15 Oct 2003 00:51:11 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id B1AB4B72; Wed, 15 Oct 2003 00:51:11 -0700 (PDT) Date: Wed, 15 Oct 2003 00:51:11 -0700 From: Kris Kennaway To: Marcel Moolenaar Message-ID: <20031015075111.GA52914@rot13.obsecurity.org> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20031015074437.GA60338@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4.1i cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 07:51:16 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 15, 2003 at 12:44:37AM -0700, Marcel Moolenaar wrote: > Yes. The MI code is already done and there's not much MD code that > is expected to break. It's mostly the structures that change. This > is especially painful on sparc64 because it's big-endian. I assume > that sparc64 passes syscall arguments in registers, so the syscalls > that take a time_t do not change except that there's no sign extension > prior to use. You can preserve the ABI until 2038 by ignoring the > upper 32-bits in that case. I'd much prefer we get it over with now before sparc64 gets widely deployed. It's going to be much more painful once there's an installed user base running production 5.x-STABLE systems. Kris --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/jPxvWry0BWjoQKURAqyfAJ4+6W0qCOKmnJCGK0vL5O62lqf0KACgx7WM QR3DnnQe7HwhrFXAEOIKvGg= =ut9a -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 01:57:13 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC90816A4BF for ; Wed, 15 Oct 2003 01:57:13 -0700 (PDT) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id E573243FE1 for ; Wed, 15 Oct 2003 01:57:10 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 12486 invoked from network); 15 Oct 2003 08:57:10 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Oct 2003 08:57:10 -0000 Received: from hydrogen.funkthat.com (pkdapa@localhost.funkthat.com [127.0.0.1])h9F8v9Ce027134; Wed, 15 Oct 2003 01:57:09 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id h9F8uxLS027133; Wed, 15 Oct 2003 01:56:59 -0700 (PDT) Date: Wed, 15 Oct 2003 01:56:59 -0700 From: John-Mark Gurney To: Marcel Moolenaar Message-ID: <20031015085659.GX533@funkthat.com> Mail-Followup-To: Marcel Moolenaar , Harti Brandt , standards@freebsd.org, Bruce Evans , sparc64@freebsd.org References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031015074437.GA60338@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 08:57:13 -0000 Marcel Moolenaar wrote this message on Wed, Oct 15, 2003 at 00:44 -0700: > Yes. The MI code is already done and there's not much MD code that > is expected to break. It's mostly the structures that change. This > is especially painful on sparc64 because it's big-endian. I assume > that sparc64 passes syscall arguments in registers, so the syscalls > that take a time_t do not change except that there's no sign extension > prior to use. You can preserve the ABI until 2038 by ignoring the > upper 32-bits in that case. There is if you load a signed 32bit value into the register... sparc will automaticly sign extend the register when loading a 32bit value.. This was done to be backwards compatible with sparcv8. So the question is, does the values get loaded into different registers? or are they packed into a single register? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 02:02:47 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A54A16A4B3; Wed, 15 Oct 2003 02:02:47 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9428743F93; Wed, 15 Oct 2003 02:02:39 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9F92WD22670; Wed, 15 Oct 2003 11:02:32 +0200 (MEST) Date: Wed, 15 Oct 2003 11:02:32 +0200 (CEST) From: Harti Brandt To: John-Mark Gurney In-Reply-To: <20031015085659.GX533@funkthat.com> Message-ID: <20031015105841.C57857@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015085659.GX533@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: sparc64@freebsd.org cc: Marcel Moolenaar Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 09:02:47 -0000 On Wed, 15 Oct 2003, John-Mark Gurney wrote: JG>Marcel Moolenaar wrote this message on Wed, Oct 15, 2003 at 00:44 -0700: JG>> Yes. The MI code is already done and there's not much MD code that JG>> is expected to break. It's mostly the structures that change. This JG>> is especially painful on sparc64 because it's big-endian. I assume JG>> that sparc64 passes syscall arguments in registers, so the syscalls JG>> that take a time_t do not change except that there's no sign extension JG>> prior to use. You can preserve the ABI until 2038 by ignoring the JG>> upper 32-bits in that case. JG> JG>There is if you load a signed 32bit value into the register... sparc JG>will automaticly sign extend the register when loading a 32bit value.. JG>This was done to be backwards compatible with sparcv8. JG> JG>So the question is, does the values get loaded into different registers? JG>or are they packed into a single register? I guess, IF we go the road now to change time_t to 64 bit, we should NOW break the ABI (if this change breaks the ABI). This brings us more in line with other systems and platforms and is a lot less problematic now that we have only -current than later. I suggest we do it NOW especially given that ia64 already does this and, obviously, has worked out the MI problems. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 11:56:47 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4048916A4B3; Wed, 15 Oct 2003 11:56:47 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3593A43FBF; Wed, 15 Oct 2003 11:56:46 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.10/8.12.9) with ESMTP id h9FIueF1024985; Wed, 15 Oct 2003 14:56:41 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031015075111.GA52914@rot13.obsecurity.org> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> <20031015075111.GA52914@rot13.obsecurity.org> Date: Wed, 15 Oct 2003 14:56:39 -0400 To: Kris Kennaway , Marcel Moolenaar From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 18:56:47 -0000 At 12:51 AM -0700 10/15/03, Kris Kennaway wrote: >On Wed, Oct 15, 2003, Marcel Moolenaar wrote: > > > Yes. The MI code is already done and there's not much MD > > code that is expected to break. It's mostly the structures > > that change. ... > >I'd much prefer we get it over with now before sparc64 gets >widely deployed. It's going to be much more painful once >there's an installed user base running production 5.x-STABLE >systems. I agree it would be better if we had 64-bit time_t's for 5.x-STABLE. I would really really like to see that. However, we are hoping to make 5.x turn into 5.x-stable with a release of 5.2 in December. We have plenty of other things which are already in the TO-DO list for 5.2, and I think it's just too late in the cycle to toss this change into the mix. In a different message, Marcel Moolenaar wrote: >BTW: time_t on ia64 is already 64 bit. Our current lineup is: alpha: typedef __int32_t __time_t; arm: typedef __int32_t __time_t; i386: typedef __int32_t __time_t; powerpc: typedef __int32_t __time_t; sparc64: typedef __int32_t __time_t; amd64: typedef __int64_t __time_t; ia64: typedef __int64_t __time_t; I could see moving powerpc to 64-bit, since that is still very much work in progress. If the powerpc port is broken by this change, we would not have to delay 5.2 for it. If there is some unpleasant fallout in changing time_t for sparc64, then we will have to delay 5.2 until all of those side-effects are sorted out. Either that, or delay "5.x-stable" to 5.3-release. And if we delay 5.x-stable to 5.3-release, then we'll find ourselves two months before 5.3-release and saying "We really should make change now, instead of waiting for 6.x-stable", and it'll be the same thing all over again. There is *always* a major change that we'd rather get done "now" instead of waiting for the next major release. This is particularly true as the time between major releases gets stretched to four or more years. So, I'd love to have it, but I think we should wait for 6.0. IMO. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 12:09:53 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FB0816A4B3; Wed, 15 Oct 2003 12:09:53 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DA6643F3F; Wed, 15 Oct 2003 12:09:52 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h9FJ9pbe000690; Wed, 15 Oct 2003 12:09:51 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.9/8.12.9/Submit) id h9FJ9pV4000689; Wed, 15 Oct 2003 12:09:51 -0700 (PDT) (envelope-from marcel) Date: Wed, 15 Oct 2003 12:09:51 -0700 From: Marcel Moolenaar To: Garance A Drosihn Message-ID: <20031015190951.GA638@ns1.xcllnt.net> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> <20031015075111.GA52914@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: standards@freebsd.org cc: sparc64@freebsd.org cc: Kris Kennaway Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 19:09:53 -0000 On Wed, Oct 15, 2003 at 02:56:39PM -0400, Garance A Drosihn wrote: > > I agree it would be better if we had 64-bit time_t's for > 5.x-STABLE. I would really really like to see that. However, > we are hoping to make 5.x turn into 5.x-stable with a release > of 5.2 in December. In fact, 5-stable happens no sooner than 5.3 in Feb 2004. Make the switch before 5.2 and you have enough time to deal with ports that suddenly start to break. Since sparc64 is already labeled tier 1, I would suggest we spend the rest of this month (= 2 weeks) getting feedback from the field. If the resistance is small enough, we make the switch early Nov. and use the remaining time to 5.2 as a shake-out period of src. We then use the time between 5.2 and 5.3 to shake out problems in ports. No mistakes: "we" does not include "marcel" :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 13:12:51 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CD8516A4EC; Wed, 15 Oct 2003 13:12:51 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63ABD43F85; Wed, 15 Oct 2003 13:12:48 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.10/8.12.9) with ESMTP id h9FKCkF1012959; Wed, 15 Oct 2003 16:12:46 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031015190951.GA638@ns1.xcllnt.net> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> <20031015075111.GA52914@rot13.obsecurity.org> <20031015190951.GA638@ns1.xcllnt.net> Date: Wed, 15 Oct 2003 16:12:44 -0400 To: Marcel Moolenaar From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: standards@freebsd.org cc: sparc64@freebsd.org cc: Kris Kennaway Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 20:12:51 -0000 At 12:09 PM -0700 10/15/03, Marcel Moolenaar wrote: >On Wed, Oct 15, 2003, Garance A Drosihn wrote: > > >> I agree it would be better if we had 64-bit time_t's for >> 5.x-STABLE. I would really really like to see that. However, >> we are hoping to make 5.x turn into 5.x-stable with a release >> of 5.2 in December. > >In fact, 5-stable happens no sooner than 5.3 in Feb 2004. Make >the switch before 5.2 and you have enough time to deal with >ports that suddenly start to break. Oh. I thought it was going to be 5.2. Well, I'm still uneasy about making the change, but I don't object quite as much if we aren't shooting for -stable in 5.2. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-standards@FreeBSD.ORG Wed Oct 15 23:26:02 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC13716A4B3 for ; Wed, 15 Oct 2003 23:26:02 -0700 (PDT) Received: from smtp.noos.fr (nan-smtp-03.noos.net [212.198.2.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E36143F93 for ; Wed, 15 Oct 2003 23:25:59 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 8600606 invoked by uid 0); 16 Oct 2003 06:22:43 -0000 Received: (qmail 7735956 invoked by uid 0); 15 Oct 2003 07:07:26 -0000 Received: from unknown (HELO mx2.freebsd.org) ([216.136.204.119]) (envelope-sender ) by 212.198.2.72 (qmail-ldap-1.03) with SMTP for ; 15 Oct 2003 07:07:26 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 71B3556263; Wed, 15 Oct 2003 00:07:23 -0700 (PDT) (envelope-from owner-freebsd-sparc64@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 99B4416A4D7; Wed, 15 Oct 2003 00:07:22 -0700 (PDT) Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E5616A4B3; Wed, 15 Oct 2003 00:06:50 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221F843FAF; Wed, 15 Oct 2003 00:06:46 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9F76cD05857; Wed, 15 Oct 2003 09:06:38 +0200 (MEST) Date: Wed, 15 Oct 2003 09:06:38 +0200 (CEST) From: Harti Brandt To: Marcel Moolenaar In-Reply-To: <20031014225053.GA59096@dhcp01.pn.xcllnt.net> Message-ID: <20031015090422.M57857@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-sparc64@freebsd.org Errors-To: owner-freebsd-sparc64@freebsd.org cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2003 06:26:03 -0000 On Tue, 14 Oct 2003, Marcel Moolenaar wrote: MM>On Wed, Oct 15, 2003 at 05:28:08AM +1000, Bruce Evans wrote: MM>> > MM>> > I guess we have to do this work before 2038, don't we? If we don't do it MM>> > before 5.2 we have to stick with this until 6.0. Correct? MM>> MM>> Yes. MM>> MM>> It is too late to change it for 5.n IMO. Every syscall that uses a time_t MM>> or a timeval would need to be duplicated. MM> MM>I'd rather we create a new sysent and prune the syscalls to get rid of MM>other compatibility cruft. It also allows us change userland visible MM>structures to make them more LP64 friendly. MM> MM>BTW: time_t on ia64 is already 64 bit. Hmm. In this case it should be rather easy to change sparc64's time_t to 64bit? The only changes should be in MD code (in theory). But this would clearly break existing installations, so I guess we'd rather wait until the fork of 6. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org _______________________________________________ freebsd-sparc64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" From owner-freebsd-standards@FreeBSD.ORG Thu Oct 16 03:47:49 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEC5816A4B3; Thu, 16 Oct 2003 03:47:48 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F8BD43FDF; Thu, 16 Oct 2003 03:47:46 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9GAlcD15572; Thu, 16 Oct 2003 12:47:38 +0200 (MEST) Date: Thu, 16 Oct 2003 12:47:37 +0200 (CEST) From: Harti Brandt To: Garance A Drosihn In-Reply-To: Message-ID: <20031016123335.L57857@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015075111.GA52914@rot13.obsecurity.org> <20031015190951.GA638@ns1.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kris Kennaway cc: standards@freebsd.org cc: sparc64@freebsd.org cc: Marcel Moolenaar Subject: Re: time_t on sparc64 (it seems to work) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2003 10:47:49 -0000 On Wed, 15 Oct 2003, Garance A Drosihn wrote: GAD>At 12:09 PM -0700 10/15/03, Marcel Moolenaar wrote: GAD>>On Wed, Oct 15, 2003, Garance A Drosihn wrote: GAD>> > GAD>>> I agree it would be better if we had 64-bit time_t's for GAD>>> 5.x-STABLE. I would really really like to see that. However, GAD>>> we are hoping to make 5.x turn into 5.x-stable with a release GAD>>> of 5.2 in December. GAD>> GAD>>In fact, 5-stable happens no sooner than 5.3 in Feb 2004. Make GAD>>the switch before 5.2 and you have enough time to deal with GAD>>ports that suddenly start to break. GAD> GAD>Oh. I thought it was going to be 5.2. Well, I'm still uneasy GAD>about making the change, but I don't object quite as much if GAD>we aren't shooting for -stable in 5.2. Well, I tried to get a first impression on how hard this change would be. I have a ultra-10 to play with. The only thing I did (after a couple of greps in sys/sparc64) was to change __time_t to __int64_t. I then recompiled everything and installed the new kernel. Just for fun I booted the kernel and - hey - it works. It comes even in multiuser mode, albeit without NFS file systems. I then rebooted the old kernel and did a make installworld. I expected this to fail at some place, because it would use the new tools (which expect 64bit time_t from the kernel) on the old kernel. It goes quite far - the stopper is zic which enters an endless loop. I stopped the install and rebooted the new kernel into single user, mounted my NFS file systems (my src and obj are on a server) by hand and tried the make install again. This time it stopped in include, probably because it was now using the old make which couldn't correctly resolve the file times anymore. I installed the new make handish and tried the installworld again. This time it stopped in sendmail, because the old find doesn't work as expected. Installing the new find did the trick. After a mergemaster and a reboot everything seems to be just fine. Of course you need to recompile all ports (unless you know which port won't used stat() or gettimeofday(). So given that things are quite simple I would argue to do the move now, before the sparc port will really be used as -stable in production systems. With a little help from the build infrastructure people it may be possible to ensure that the above will work more automatically. Also the sparc gurus should probably have a look at the MD parts, whether there is something that needs to be changed. So when will we do it? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Fri Oct 17 12:27:59 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CE5516A4B3; Fri, 17 Oct 2003 12:27:59 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3834F43FAF; Fri, 17 Oct 2003 12:27:58 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.10/8.12.9) with ESMTP id h9HJRu8j016332; Fri, 17 Oct 2003 15:27:56 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031016123335.L57857@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> <20031015075111.GA52914@rot13.obsecurity.org> <20031015190951.GA638@ns1.xcllnt.net> <20031016123335.L57857@beagle.fokus.fraunhofer.de> Date: Fri, 17 Oct 2003 15:27:54 -0400 To: harti@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: Kris Kennaway cc: standards@freebsd.org cc: sparc64@freebsd.org cc: Marcel Moolenaar Subject: Re: time_t on sparc64 (it seems to work) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2003 19:27:59 -0000 At 12:47 PM +0200 10/16/03, Harti Brandt wrote: > >Well, I tried to get a first impression on how hard this >change would be. I have a ultra-10 to play with. > >The only thing I did (after a couple of greps in sys/sparc64) >was to change __time_t to __int64_t. I then recompiled >everything and installed the new kernel. Just for fun I booted >the kernel and - hey - it works. ... >rebooted the new kernel into single user, mounted my NFS file >systems (my src and obj are on a server) by hand and tried the >make install again. This time it stopped in include, probably >because it was now using the old make which couldn't correctly >resolve the file times anymore. I installed the new make >handish and tried the installworld again. This time it stopped >in sendmail, because the old find doesn't work as expected. >Installing the new find did the trick. After a mergemaster and >a reboot everything seems to be just fine. >So given that things are quite simple I would argue to do the >move now, before the sparc port will really be used as -stable >in production systems. I would say that your own description falls a little short of being "quite simple"... >Of course you need to recompile all ports (unless you know >which port won't used stat() or gettimeofday(). Which is even more work that every-sparc64-user would have to do. It also means that there is a lot that you have not really tested with the above. It also means that any pkg-building will have provide packages for both 64-bit and 32-bit time_t systems, unless you can somehow get everyone to rebuild their systems on the same day. >With a little help from the build infrastructure people it >may be possible to ensure that the above will work more >automatically. But that is also "more work" for some developers would have to do, and they'd have to do it "right now". >So when will we do it? I definitely do like the idea of getting to 64-bit time_t on sparc64 before 5.2-release, but there is no question that it adds to the work necessary before "5.x" becomes "5.x-stable". If we are going to do it, we should talk as if we are going to do it "Right Now", or we should admit that it must wait until 6.0-current. I am willing to go through the same steps that you went through to get my one (1) sparc64 system to be running with 64-bit timestamps. I'm willing to recompile all the ports on mine. However, I don't really use my sparc64 system for all that much, and I can afford to erase the disk and start over if this really botches things up. And even if everything that I do works fine, that won't be much of a test. There is a lot of stuff that I do NOT do which someone would be doing if they used a sparc64 system as their primary desktop machine. So I am willing to try to do a 64-bit time_t on my one system, but only if there is a list of others who are going to do the same thing. We're only going to get from "here" to "there" if we start working on it, and we must see multiple developers stepping up Right Now who are willing to do that work (even if it's just testing-work, it has to be done). Otherwise, let's concentrate on getting to 5.x-stable, and put off all talk of 64-bit time_t's until we create 6.0-current. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-standards@FreeBSD.ORG Fri Oct 17 22:50:04 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B6616A4B3; Fri, 17 Oct 2003 22:50:04 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D51343F75; Fri, 17 Oct 2003 22:50:04 -0700 (PDT) (envelope-from tjr@FreeBSD.org) Received: from freefall.freebsd.org (tjr@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9I5o4FY059398; Fri, 17 Oct 2003 22:50:04 -0700 (PDT) (envelope-from tjr@freefall.freebsd.org) Received: (from tjr@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9I5o3FV059394; Fri, 17 Oct 2003 22:50:03 -0700 (PDT) (envelope-from tjr) Date: Fri, 17 Oct 2003 22:50:03 -0700 (PDT) From: "Tim J. Robbins" Message-Id: <200310180550.h9I5o3FV059394@freefall.freebsd.org> To: wollman@lcs.mit.edu, tjr@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/40669: command command does not support `-p' option X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2003 05:50:04 -0000 Synopsis: command command does not support `-p' option State-Changed-From-To: patched->closed State-Changed-By: tjr State-Changed-When: Fri Oct 17 22:49:32 PDT 2003 State-Changed-Why: This has been fixed in -stable for quite a while now. http://www.freebsd.org/cgi/query-pr.cgi?pr=40669