From owner-freebsd-arch Sun Oct 21 10: 1:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 6494937B434 for ; Sun, 21 Oct 2001 10:01:06 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9LH0gO02445; Sun, 21 Oct 2001 10:00:42 -0700 (PDT) (envelope-from obrien) Date: Sun, 21 Oct 2001 10:00:42 -0700 From: "David O'Brien" To: "Andrey A. Chernov" Cc: arch@freebsd.org Subject: Re: "pop", "www" & others result? Message-ID: <20011021100042.B2340@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20011020172953.A7618@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011020172953.A7618@nagual.pp.ru>; from ache@nagual.pp.ru on Sat, Oct 20, 2001 at 05:29:54PM +0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Sat, Oct 20, 2001 at 05:29:54PM +0400, Andrey A. Chernov wrote: > Well, I don't understand which solution we finally choose: > > 1) Add "pop", "www" and some other commonly used to master.passwd > 2) Remove "pop", don't add "www" and some others. Just disconnect your email for 3 days and go with #1 and be done with it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 21 13:17:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id A93FD37B401; Sun, 21 Oct 2001 13:17:53 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id f9LKHqT75339; Mon, 22 Oct 2001 00:17:52 +0400 (MSD) (envelope-from ache) Date: Mon, 22 Oct 2001 00:17:51 +0400 From: "Andrey A. Chernov" To: "David O'Brien" Cc: arch@freebsd.org Subject: Re: "pop", "www" & others result? Message-ID: <20011022001751.A75317@nagual.pp.ru> References: <20011020172953.A7618@nagual.pp.ru> <20011021100042.B2340@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011021100042.B2340@dragon.nuxi.com> User-Agent: Mutt/1.3.23i 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 On Sun, Oct 21, 2001 at 10:00:42 -0700, David O'Brien wrote: > On Sat, Oct 20, 2001 at 05:29:54PM +0400, Andrey A. Chernov wrote: > > Well, I don't understand which solution we finally choose: > > > > 1) Add "pop", "www" and some other commonly used to master.passwd ^^^ I mean left "pop" in place, add "www". > > 2) Remove "pop", don't add "www" and some others. > > Just disconnect your email for 3 days and go with #1 and be done with it. Good idea. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 21 13:36: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A3EE137B401; Sun, 21 Oct 2001 13:35:55 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f9LKYcV40345; Sun, 21 Oct 2001 14:34:39 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id f9LKYW761949; Sun, 21 Oct 2001 14:34:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200110212034.f9LKYW761949@harmony.village.org> To: Mike Smith Subject: Re: exporting device info via sysctl ? Cc: Robert Watson , Peter Wemm , Luigi Rizzo , arch@FreeBSD.ORG, msmith@mass.dis.org In-reply-to: Your message of "Tue, 16 Oct 2001 15:23:38 PDT." <200110162223.f9GMNcr03750@mass.dis.org> References: <200110162223.f9GMNcr03750@mass.dis.org> Date: Sun, 21 Oct 2001 14:34:32 -0600 From: Warner Losh 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 In message <200110162223.f9GMNcr03750@mass.dis.org> Mike Smith writes: : devinfo is probably worthy of a junior hacker project; it needs a : manpage and some extensions, as well as some fixes (eg. it doesn't deal well : with shared resources). and it doesn't tell you that devices are in the tree, but not attached. :-( Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 21 13:45:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id B21C537B401; Sun, 21 Oct 2001 13:45:21 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9LKvRi01189; Sun, 21 Oct 2001 13:57:27 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110212057.f9LKvRi01189@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Warner Losh Cc: Mike Smith , Robert Watson , Peter Wemm , Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: exporting device info via sysctl ? In-reply-to: Your message of "Sun, 21 Oct 2001 14:34:32 MDT." <200110212034.f9LKYW761949@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Oct 2001 13:57:27 -0700 From: Mike Smith 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 > In message <200110162223.f9GMNcr03750@mass.dis.org> Mike Smith writes: > : devinfo is probably worthy of a junior hacker project; it needs a > : manpage and some extensions, as well as some fixes (eg. it doesn't deal wel > l > : with shared resources). > > and it doesn't tell you that devices are in the tree, but not > attached. :-( You mean it doesn't tell you about device instances with unattached drivers? Yeah, its view of the tree is a bit simplistic; there were a lot of things I decided were "too hard" for the first iteration. And now I don't really have time to work on it anymore. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 21 14:44:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E3F2437B401; Sun, 21 Oct 2001 14:44:44 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f9LLihV40665; Sun, 21 Oct 2001 15:44:43 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id f9LLia762445; Sun, 21 Oct 2001 15:44:40 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200110212144.f9LLia762445@harmony.village.org> To: Mike Smith Subject: Re: exporting device info via sysctl ? Cc: Robert Watson , Peter Wemm , Luigi Rizzo , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Oct 2001 13:57:27 PDT." <200110212057.f9LKvRi01189@mass.dis.org> References: <200110212057.f9LKvRi01189@mass.dis.org> Date: Sun, 21 Oct 2001 15:44:36 -0600 From: Warner Losh 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 In message <200110212057.f9LKvRi01189@mass.dis.org> Mike Smith writes: : > In message <200110162223.f9GMNcr03750@mass.dis.org> Mike Smith writes: : > : devinfo is probably worthy of a junior hacker project; it needs a : > : manpage and some extensions, as well as some fixes (eg. it doesn't deal wel : > l : > : with shared resources). : > : > and it doesn't tell you that devices are in the tree, but not : > attached. :-( : : You mean it doesn't tell you about device instances with unattached : drivers? Yeah, its view of the tree is a bit simplistic; there were a : lot of things I decided were "too hard" for the first iteration. Yes. If a driver is in the tree, it reports it, even if it is unattached :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 22 6:46:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by hub.freebsd.org (Postfix) with ESMTP id 6E7DE37B405 for ; Mon, 22 Oct 2001 06:46:17 -0700 (PDT) Received: by gvr.gvr.org (Postfix, from userid 657) id 441F35808; Mon, 22 Oct 2001 15:46:15 +0200 (CEST) Date: Mon, 22 Oct 2001 15:46:15 +0200 From: Guido van Rooij To: Dag-Erling Smorgrav Cc: Will Andrews , arch@FreeBSD.org Subject: Re: New rc.d init script roadmap Message-ID: <20011022154615.A42579@gvr.gvr.org> References: <20011018163033.C57251@squall.waterspout.com> <20011018164026.A25747@squall.waterspout.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from des@ofug.org on Fri, Oct 19, 2001 at 12:12:31AM +0200 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 On Fri, Oct 19, 2001 at 12:12:31AM +0200, Dag-Erling Smorgrav wrote: > > This issue is sufficiently complex that I actually think a small > well-thought-out special-purpose script language would be better > suited to this task that a bunch of shell scripts + rcorder, but > that is probably a far too politically controversial suggestion. > > (it's all a matter of interdependent objects on which you can perform > various operations, so a Real Hacker would come up with a lightweight > object-oriented script language that could not only manage the startup > sequence but replace make(1) as well. > Since checking is done differently per service, it makes most sense to me to put the checks in the service scripts. That means that non-standard services like ipfilter must implement there own ipfilter_cmd scripts and skip the start command if alread started. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 22 23:55:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 1686537B403; Mon, 22 Oct 2001 23:55:30 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA92606; Tue, 23 Oct 2001 01:01:52 -0700 (PDT) Message-ID: <3BD5100A.2D09B278@elischer.org> Date: Mon, 22 Oct 2001 23:36:58 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jonathan Lemon Cc: John Baldwin , Peter Wemm , arch@FreeBSD.ORG, Warner Losh Subject: Re: Style Wars References: <20010928233146.8959B3809@overcee.netplex.com.au> <20010928185913.U9056@prism.flugsvamp.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit 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 I hate to bring this up again, but I almost threw up when I went to look at proc.h after david 'style(9)'d it. (It looks like the result of same). (Not David's fault, but style(9)..) I propose that we modify the following prargraph in style(9) from: When declaring variables in structures, declare them sorted by use, then by size, and then by alphabetical order. The first category normally doesn't apply, but there are exceptions. Each one gets its own line. Put a tab after the first word, i.e. use `int^Ix;' and `struct^Ifoo *x;'. to: When declaring variables in structures, declare them sorted by use, then by size, and then by alphabetical order. The first category normally doesn't apply, but there are exceptions. Try to make the structure readable by aligning the variable names using either one or two tabs depending upon your judgement. Names following extremely long types should be separated by a simple space. i.e. use int^I^Ix; and struct foo^I*x; and struct verylongtypename *bar; This approximates 1b). If I don't hear a large outcry (it was a loud 'yes' last time but I didn't see an agreement that it should be done) then I'd like to make that change. Jonathan Lemon wrote: > > On Fri, Sep 28, 2001 at 04:54:01PM -0700, John Baldwin wrote: > > > > On 28-Sep-01 Peter Wemm wrote: > > > John Baldwin wrote: > > >> [ moved to -arch ] > > >> > > >> On 28-Sep-01 Julian Elischer wrote: > > >> > well maybe We can come up with a tweek to the standard that we can > > >> > all agree to... > > >> > and commit.. It is after all a 'living' document.. > > >> > > >> Certainly a viable option. I've seen a couple of ideas so far: > > >> > > >> 1) Use two tabs instead of one when types longer than one tab such > > >> as u_int64_t are used. > > >> 1a) Same as 1) but the tabs after after the type, not just the > > >> first word. > > > > > > 1b) Same as 1a), but also with 2) for types longer than two tabs. > > > ie: "struct verylongtypename *foo;" > > > > > >> 2) Use a space instead of a tab after types longer than one tab like > > >> we already do for queue macros. > > > > I'm think 1b) is the one most people have favored so far and it is rather close > > to our existing style, so it's not that big of a change. Does anyone object to > > 1b)? It basically results in the following changes: use 2 tab spaces instead > > of 1 for type names, put the entire type name before the tab(s), and if the > > type is too long, just use a space. > > I prefer 1) (and the 1b variant), but not 1a). (e.g.: ) > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 22 23:57:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B516A37B406; Mon, 22 Oct 2001 23:57:43 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f9N6vfV48163; Tue, 23 Oct 2001 00:57:42 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id f9N6ve716142; Tue, 23 Oct 2001 00:57:40 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200110230657.f9N6ve716142@harmony.village.org> To: Julian Elischer Subject: Re: Style Wars Cc: Jonathan Lemon , John Baldwin , Peter Wemm , arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 22 Oct 2001 23:36:58 PDT." <3BD5100A.2D09B278@elischer.org> References: <3BD5100A.2D09B278@elischer.org> <20010928233146.8959B3809@overcee.netplex.com.au> <20010928185913.U9056@prism.flugsvamp.com> Date: Tue, 23 Oct 2001 00:57:40 -0600 From: Warner Losh 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 In message <3BD5100A.2D09B278@elischer.org> Julian Elischer writes: : When declaring variables in structures, declare them sorted by use, then : by size, and then by alphabetical order. The first category normally : doesn't apply, but there are exceptions. Try to make the structure : readable by aligning the variable names using either one or two tabs : depending upon your judgement. Names following extremely long types : should be separated by a simple space. i.e. use int^I^Ix; and : struct foo^I*x; and struct verylongtypename *bar; : : : This approximates 1b). : : If I don't hear a large outcry (it was a loud 'yes' last time but I didn't : see an agreement that it should be done) then I'd like to make that change. That was the approximate consensus that we had. I think as such, it should be committed w/o revisting the discussion :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 5:22:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9B2F237B401; Tue, 23 Oct 2001 05:22:46 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 11A6C14C2E; Tue, 23 Oct 2001 14:22:44 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Julian Elischer Cc: Jonathan Lemon , John Baldwin , Peter Wemm , arch@FreeBSD.ORG, Warner Losh Subject: Re: Style Wars References: <20010928233146.8959B3809@overcee.netplex.com.au> <20010928185913.U9056@prism.flugsvamp.com> <3BD5100A.2D09B278@elischer.org> From: Dag-Erling Smorgrav Date: 23 Oct 2001 14:22:44 +0200 In-Reply-To: <3BD5100A.2D09B278@elischer.org> Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Julian Elischer writes: > When declaring variables in structures, declare them sorted by use, then > by size, and then by alphabetical order. The first category normally > doesn't apply, but there are exceptions. Try to make the structure > readable by aligning the variable names using either one or two tabs > depending upon your judgement. Names following extremely long types > should be separated by a simple space. i.e. use int^I^Ix; and > struct foo^I*x; and struct verylongtypename *bar; Yes, please! DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 6: 0:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 41CFF37B412 for ; Tue, 23 Oct 2001 06:00:15 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2CAE714C2E; Tue, 23 Oct 2001 15:00:14 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: Debugging interfaces From: Dag-Erling Smorgrav Date: 23 Oct 2001 15:00:13 +0200 Message-ID: Lines: 83 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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 --=-=-= We currently have three distinct debugging interfaces in the system: ktrace(2), ptrace(2) and procfs(5). I think you'll all agree that that's two too many. I propose to remove at least one of them. The arguments in favor of ktrace is that it is easy to use (and to extend) and provides information that ptrace and procfs cannot provide (e.g. namei translations). The argument against it is that it does its work by stealing the traced process' context to write the debugging information directly to a file. It works for now, but it may break in interesting ways as we continue pushing down locks. The arguments in favor of ptrace is that it's clean and simple (which makes it easy to audir) and doesn't invade the kernel much; it does its work in the context of the calling process (i.e. the debugger), not that of the target process. The arguments against it is that it is underpowered (there are things it can't do that e.g. truss needs to do its job) and it reparents the debugged process, which is a bummer if you use its parent is in wait4(). The arguments in favor of procfs is that it is currently the only debugging interface that can do pretty much everything you need, and it doesn't reparent the target process. The arguments against it are... well, it's procfs. It's vile and intrusive and has a history of security holes. It'd be nice to be able to truss processes without needing procfs. Plus, the way the procfs debugging interface is designed, it can leave a process stuck in a loop in stopevent() and there's nothing you can do to kill it unless you re-attach to it using truss or procctl. What I suggest is: 1) Leave ktrace alone. It's a kernel option, so people who don't like it can disable it. Maybe remove it from GENERIC and change the message ktrace(1) prints when run on a KTRACE-less kernel to "re-compile kernel with 'options KTRACE' or use truss". 2) Extend ptrace so it can support truss. 3) Rewrite truss to use ptrace instead of procfs. 4) Dyke out the pioctl stuff from procfs. I have items 2) and 3) nearly done (to the point where 'truss -dS -o truss.out ls' produces the attached truss.out; you'll notice that it's not yet smart enough to display string arguments). I've changed stopevent() so it stops the process (roughly "p->p_stat = SSTOP; mi_switch();") instead of looping, so the debugging process can use wait4() instead of the PIOCWAIT ioctl to wait for events. In order to support following forks in the debugged process without upsetting the parent process (i.e. without reparenting the debugged process), I need to make a few changes to struct proc and wait4(); - struct proc acquires mirror p_pptr, p_sibling and p_children for debugging purposes p_dpptr pointer to debugging "parent" p_dsibling list of sibling debugged processes p_dchildren pointer to list of debugging "children" - instead of waking up the parent process, stopevent() will wake up the debugging parent. - wait4() will scan p_dchildren in addition to p_children. In addition, when a debugging process dies, any processes it was debugging will be "undebugged" so you can no longer have processes stuck in stopevent(). Some fields in struct proc (p_pfsflags for instance) will disappear as a consequence of item 4) above. None of these changes will affect the (limited) way gdb uses ptrace. Comments are welcome. I estimate I will have patches ready for review by the end of this week. DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Disposition: attachment; filename=truss.out 4978 00:00.002 ptrace(0x0, 0x0, 0x0, 0x0) 4978 00:00.003 ptrace returned 0 4978 00:00.004 execve(0xbfbff214, 0xbfbff6c8, 0xbfbff6d0) 4978 00:00.004 execve returned error 2: No such file or directory 4978 00:00.004 execve(0xbfbff214, 0xbfbff6c8, 0xbfbff6d0) 4978 00:00.005 execve returned error 2: No such file or directory 4978 00:00.005 execve(0xbfbff214, 0xbfbff6c8, 0xbfbff6d0) 4978 00:00.005 execve returned error 2: No such file or directory 4978 00:00.005 execve(0xbfbff214, 0xbfbff6c8, 0xbfbff6d0) 4978 00:00.007 exec 4978 00:00.007 execve returned 0 4978 00:00.008 open(fn = 0xbfbfebe0, flags = 0x0, mode = 0666) 4978 00:00.008 open returned 4 4978 00:00.009 fstat(0x4, 0xbfbfeab0) 4978 00:00.009 fstat returned 0 4978 00:00.009 readlink(0x80aef14, 0xbfbfea90, 0x3f) 4978 00:00.009 readlink returned 1 4978 00:00.010 __syscall(0xc5, 0x0, 0x0, 0x1000, 0x3, 0x1002, 0xffffffff, 0x0) 4978 00:00.010 __syscall returned 671821824 4978 00:00.010 break(0x80c9000) 4978 00:00.011 break returned 0 4978 00:00.011 break(0x80cb000) 4978 00:00.011 break returned 0 4978 00:00.011 read(fd = 4, buf = 0x80c9000, len = 8192) 4978 00:00.012 read returned 6618 4978 00:00.012 close(fd = 4) 4978 00:00.012 close returned 0 4978 00:00.013 open(fn = 0xbfbfebe0, flags = 0x0, mode = 0666) 4978 00:00.013 open returned 4 4978 00:00.013 fstat(0x4, 0xbfbfeb50) 4978 00:00.013 fstat returned 0 4978 00:00.014 fstat(0x4, 0xbfbfe9a0) 4978 00:00.014 fstat returned 0 4978 00:00.014 break(0x80cd000) 4978 00:00.014 break returned 0 4978 00:00.014 __syscall(0xc7, 0x0, 0x4, 0x0, 0x0) 4978 00:00.015 __syscall returned 0 4978 00:00.015 __syscall(0xc7, 0x0, 0x4, 0x0, 0x0) 4978 00:00.015 __syscall returned 0 4978 00:00.015 read(fd = 4, buf = 0x80cb000, len = 8192) 4978 00:00.016 read returned 3196 4978 00:00.016 close(fd = 4) 4978 00:00.016 close returned 0 4978 00:00.016 open(fn = 0xbfbfeba0, flags = 0x0, mode = 01002705061) 4978 00:00.017 open returned 4 4978 00:00.017 fstat(0x4, 0xbfbfeb40) 4978 00:00.017 fstat returned 0 4978 00:00.018 read(fd = 4, buf = 0x80ca011, len = 34) 4978 00:00.018 read returned 34 4978 00:00.018 close(fd = 4) 4978 00:00.018 close returned 0 4978 00:00.018 open(fn = 0xbfbfeba0, flags = 0x0, mode = 01002705121) 4978 00:00.019 open returned 4 4978 00:00.019 fstat(0x4, 0xbfbfeb40) 4978 00:00.019 fstat returned 0 4978 00:00.019 read(fd = 4, buf = 0x80c8091, len = 8) 4978 00:00.020 read returned 8 4978 00:00.020 close(fd = 4) 4978 00:00.020 close returned 0 4978 00:00.020 open(fn = 0xbfbfebb0, flags = 0x0, mode = 01002705161) 4978 00:00.021 open returned 4 4978 00:00.021 fstat(0x4, 0xbfbfeb50) 4978 00:00.021 fstat returned 0 4978 00:00.021 read(fd = 4, buf = 0x80cb011, len = 377) 4978 00:00.022 read returned 377 4978 00:00.022 close(fd = 4) 4978 00:00.022 close returned 0 4978 00:00.022 open(fn = 0xbfbfebb0, flags = 0x0, mode = 01002705221) 4978 00:00.022 open returned 4 4978 00:00.023 fstat(0x4, 0xbfbfeb50) 4978 00:00.023 fstat returned 0 4978 00:00.023 read(fd = 4, buf = 0x80ca051, len = 18) 4978 00:00.023 read returned 18 4978 00:00.023 close(fd = 4) 4978 00:00.024 close returned 0 4978 00:00.024 ioctl(0x1, 0x402c7413, 0xbfbff014) 4978 00:00.024 ioctl returned 0 4978 00:00.024 ioctl(0x1, 0x40087468, 0xbfbff088) 4978 00:00.025 ioctl returned 0 4978 00:00.025 getuid() 4978 00:00.025 getuid returned 2602 4978 00:00.025 break(0x80ce000) 4978 00:00.025 break returned 0 4978 00:00.025 stat(0x80cd0c0, 0xbfbfef70) 4978 00:00.026 stat returned 0 4978 00:00.026 open(fn = 0x80aa2eb, flags = 0x0, mode = 00) 4978 00:00.026 open returned 4 4978 00:00.026 fchdir(0x4) 4978 00:00.027 fchdir returned 0 4978 00:00.027 open(fn = 0x80aa2eb, flags = 0x0, mode = 00) 4978 00:00.027 open returned 5 4978 00:00.027 stat(0x80cc000, 0xbfbfef30) 4978 00:00.028 stat returned 0 4978 00:00.028 open(fn = 0x80cc000, flags = 0x4, mode = 00) 4978 00:00.028 open returned 6 4978 00:00.028 fstat(0x6, 0xbfbfef30) 4978 00:00.029 fstat returned 0 4978 00:00.029 fcntl(0x6, 0x2, 0x1) 4978 00:00.029 fcntl returned 0 4978 00:00.029 __sysctl(0xbfbfede8, 0x2, 0x80c2264, 0xbfbfede4, 0x0, 0x0) 4978 00:00.030 __sysctl returned 0 4978 00:00.030 fstatfs(0x6, 0xbfbfee30) 4978 00:00.030 fstatfs returned 0 4978 00:00.030 break(0x80cf000) 4978 00:00.030 break returned 0 4978 00:00.031 getdirentries(0x6, 0x80ce000, 0x1000, 0x80ca0d4) 4978 00:00.031 getdirentries returned 1024 4978 00:00.031 getdirentries(0x6, 0x80ce000, 0x1000, 0x80ca0d4) 4978 00:00.032 getdirentries returned 0 4978 00:00.032 __syscall(0xc7, 0x0, 0x6, 0x0, 0x0) 4978 00:00.032 __syscall returned 0 4978 00:00.032 close(fd = 6) 4978 00:00.033 close returned 0 4978 00:00.033 fchdir(0x5) 4978 00:00.033 fchdir returned 0 4978 00:00.033 close(fd = 5) 4978 00:00.033 close returned 0 4978 00:00.034 fstat(0x1, 0xbfbfed30) 4978 00:00.034 fstat returned 0 4978 00:00.034 break(0x80d0000) 4978 00:00.034 break returned 0 4978 00:00.034 ioctl(0x1, 0x402c7413, 0xbfbfed64) 4978 00:00.035 ioctl returned 0 4978 00:00.035 write(fd = 1, buf = 0x80cf000, len = 46) 4978 00:00.035 write returned 46 4978 00:00.037 write(fd = 1, buf = 0x80cf000, len = 42) 4978 00:00.038 write returned 42 4978 00:00.039 write(fd = 1, buf = 0x80cf000, len = 57) 4978 00:00.040 write returned 57 4978 00:00.042 write(fd = 1, buf = 0x80cf000, len = 46) 4978 00:00.043 write returned 46 4978 00:00.044 exit(status = 0) 4978 00:00.045 exit 0 --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 7: 9:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4EFCB37B401 for ; Tue, 23 Oct 2001 07:09:15 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA27242; Wed, 24 Oct 2001 00:09:05 +1000 Date: Wed, 24 Oct 2001 00:08:10 +1000 (EST) From: Bruce Evans X-X-Sender: To: Dag-Erling Smorgrav Cc: Subject: Re: Debugging interfaces In-Reply-To: Message-ID: <20011023235726.M63643-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On 23 Oct 2001, Dag-Erling Smorgrav wrote: > We currently have three distinct debugging interfaces in the system: > ktrace(2), ptrace(2) and procfs(5). I think you'll all agree that > that's two too many. I propose to remove at least one of them. Well, one too many. It might be worth separating gdb-type debugging from program-tracing type debugging. > What I suggest is: > > 1) Leave ktrace alone. It's a kernel option, so people who don't > like it can disable it. Maybe remove it from GENERIC and change > the message ktrace(1) prints when run on a KTRACE-less kernel to > "re-compile kernel with 'options KTRACE' or use truss". > > 2) Extend ptrace so it can support truss. > > 3) Rewrite truss to use ptrace instead of procfs. > > 4) Dyke out the pioctl stuff from procfs. > > I have items 2) and 3) nearly done (to the point where 'truss -dS -o > truss.out ls' produces the attached truss.out; you'll notice that it's > not yet smart enough to display string arguments). I've changed Don't forget strace (in ports). It's like truss but is much more complete. It seems to use mainly the pioctl interface :-). Someone once said that (Linux-only at the time) strace only needed a couple of minor extensions to ptrace for it to be ported to FreeBSD. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 8:12:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B615637B401 for ; Tue, 23 Oct 2001 08:12:12 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 71CDE14C2E; Tue, 23 Oct 2001 17:12:11 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bruce Evans Cc: Subject: Re: Debugging interfaces References: <20011023235726.M63643-100000@delplex.bde.org> From: Dag-Erling Smorgrav Date: 23 Oct 2001 17:12:10 +0200 In-Reply-To: <20011023235726.M63643-100000@delplex.bde.org> Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Bruce Evans writes: > On 23 Oct 2001, Dag-Erling Smorgrav wrote: > > We currently have three distinct debugging interfaces in the system: > > ktrace(2), ptrace(2) and procfs(5). I think you'll all agree that > > that's two too many. I propose to remove at least one of them. > Well, one too many. It might be worth separating gdb-type debugging > from program-tracing type debugging. Gdb uses ptrace() and works just fine without procfs. I'm not exactly sure *how* it works though. > Don't forget strace (in ports). It's like truss but is much more > complete. It seems to use mainly the pioctl interface :-). Someone > once said that (Linux-only at the time) strace only needed a couple > of minor extensions to ptrace for it to be ported to FreeBSD. Thanks. I'll look at strace and see what needs to be done to keep it working. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 8:14:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by hub.freebsd.org (Postfix) with ESMTP id A1B4637B403 for ; Tue, 23 Oct 2001 08:14:26 -0700 (PDT) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 23 Oct 2001 16:14:18 +0100 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 15w3Es-0001zo-00; Tue, 23 Oct 2001 16:13:10 +0100 Date: Tue, 23 Oct 2001 16:13:09 +0100 (BST) From: Jan Grant X-X-Sender: To: Guido van Rooij Cc: Dag-Erling Smorgrav , Will Andrews , arch Subject: Scoping /etc/rc.d/* status Was: New rc.d init script roadmap In-Reply-To: <20011022154615.A42579@gvr.gvr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 22 Oct 2001, Guido van Rooij wrote: > On Fri, Oct 19, 2001 at 12:12:31AM +0200, Dag-Erling Smorgrav wrote: > > > > This issue is sufficiently complex that I actually think a small > > well-thought-out special-purpose script language would be better > > suited to this task that a bunch of shell scripts + rcorder, but > > that is probably a far too politically controversial suggestion. > > > > (it's all a matter of interdependent objects on which you can perform > > various operations, so a Real Hacker would come up with a lightweight > > object-oriented script language that could not only manage the startup > > sequence but replace make(1) as well. > > > > Since checking is done differently per service, it makes most sense > to me to put the checks in the service scripts. > That means that non-standard services like ipfilter must implement > there own ipfilter_cmd scripts and skip the start command if alread > started. A word about checking status. It seems to me that there are increasing complications in the situations rc.d scripts might be expected to cope with: 1. services only started and stopped through rc.d scripts; nothing ever crashes 2. services started through rc.d; things occasionally break (daemons crash) 3. services started and stopped ad hoc by the user 4. user attempts to deliberately pervert rc.d system's operation (removing PID files, etc) We clearly want to cope with at least (1), and would like scripts to cope in most situations with at least (2) and (3) reasonably gracefully. What we can guarantee for (4) is little or nothing in the general case. So it might be argued that for stuff like IPF, "faking up" a PID/status file and relying on that to hold the "running/inactive" status is "sufficiently robust". jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk On modesty: whoever said "it's hard being perfect" obviously wasn't me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 9:31:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id C4FE037B401; Tue, 23 Oct 2001 09:31:39 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9NGVdM31618; Tue, 23 Oct 2001 09:31:39 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 41177380A; Tue, 23 Oct 2001 09:31:39 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: Julian Elischer , Jonathan Lemon , John Baldwin , arch@FreeBSD.ORG, Warner Losh Subject: Re: Style Wars In-Reply-To: Date: Tue, 23 Oct 2001 09:31:39 -0700 From: Peter Wemm Message-Id: <20011023163139.41177380A@overcee.netplex.com.au> 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 Dag-Erling Smorgrav wrote: > Julian Elischer writes: > > When declaring variables in structures, declare them sorted by use, th en > > by size, and then by alphabetical order. The first category normally > > doesn't apply, but there are exceptions. Try to make the structure > > readable by aligning the variable names using either one or two tabs > > depending upon your judgement. Names following extremely long types > > should be separated by a simple space. i.e. use int^I^Ix; and > > struct foo^I*x; and struct verylongtypename *bar; > > Yes, please! Ditto. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 9:49:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 6B53037B401 for ; Tue, 23 Oct 2001 09:49:08 -0700 (PDT) Received: (qmail 90197 invoked from network); 23 Oct 2001 16:49:05 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Oct 2001 16:49:05 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200110230657.f9N6ve716142@harmony.village.org> Date: Tue, 23 Oct 2001 09:48:58 -0700 (PDT) From: John Baldwin To: Warner Losh Subject: Re: Style Wars Cc: arch@FreeBSD.ORG, Peter Wemm , Jonathan Lemon , Julian Elischer 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 On 23-Oct-01 Warner Losh wrote: > In message <3BD5100A.2D09B278@elischer.org> Julian Elischer writes: >: When declaring variables in structures, declare them sorted by use, >: then >: by size, and then by alphabetical order. The first category normally >: doesn't apply, but there are exceptions. Try to make the structure >: readable by aligning the variable names using either one or two tabs >: depending upon your judgement. Names following extremely long types >: should be separated by a simple space. i.e. use int^I^Ix; and >: struct foo^I*x; and struct verylongtypename *bar; >: >: >: This approximates 1b). >: >: If I don't hear a large outcry (it was a loud 'yes' last time but I didn't >: see an agreement that it should be done) then I'd like to make that change. > > That was the approximate consensus that we had. I think as such, it > should be committed w/o revisting the discussion :-) Agreed. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 23 21:45:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 3F0BE37B403 for ; Tue, 23 Oct 2001 21:45:48 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9O4iuU83581; Tue, 23 Oct 2001 21:44:56 -0700 (PDT) (envelope-from obrien) Date: Tue, 23 Oct 2001 21:44:56 -0700 From: "David O'Brien" To: Jan Grant Cc: Guido van Rooij , Dag-Erling Smorgrav , Will Andrews , arch Subject: Re: Scoping /etc/rc.d/* status Was: New rc.d init script roadmap Message-ID: <20011023214456.A81264@dragon.nuxi.com> Reply-To: arch@FreeBSD.org References: <20011022154615.A42579@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Jan.Grant@bristol.ac.uk on Tue, Oct 23, 2001 at 04:13:09PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Tue, Oct 23, 2001 at 04:13:09PM +0100, Jan Grant wrote: > A word about checking status. It seems to me that there are increasing > complications in the situations rc.d scripts might be expected to cope > with: ... > We clearly want to cope with at least (1), and would like scripts to > cope in most situations with at least (2) and (3) reasonably gracefully. > What we can guarantee for (4) is little or nothing in the general case. We clearly just want to get the NetBSD bits port as-is so we can gain experience with them. Right now is not the time to be redesigning them. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 9:23: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 76F9637B401; Wed, 24 Oct 2001 09:22:53 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) (authenticated as iwa with CRAM-MD5) by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare) with ESMTP/inet id f9OGMlm16160; Thu, 25 Oct 2001 01:22:47 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Thu, 25 Oct 2001 01:22:43 +0900 (JST) Message-Id: <20011025.012243.71082514.iwasaki@jp.FreeBSD.org> To: acpi-jp@jp.freebsd.org Cc: arch@freebsd.org, audit@freebsd.org Subject: ACPI: APM compatibility implementation From: Mitsuru IWASAKI X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Hi, I've just started implementation of APM compatibility stuff for FreeBSD/i386. The goal is to support most APM applications (binary) w/o any changes on ACPI enabled kernel. This emulates APM device node interface APIs (mainly ioctl) and provides APM services for the applications. The patches at: http://people.freebsd.org/~iwasaki/acpi/acpi_compat_apm-20011025.diff Currently following ioctls are implemented; - APMIO_SUSPEND (mapped S3 as default but can be changed by sysctl) - APMIO_STANDBY (mapped S1 as default but can be changed by sysctl) - APMIO_GETINFO and APMIO_GETINFO_OLD - APMIO_GETPWSTATUS Many APM applications are already supported. apmopen, apmclose, apmwrite, apmpoll and following ioctls are fake :-p - APMIO_ENABLE - APMIO_DISABLE - APMIO_HALTCPU - APMIO_NOTHALTCPU - APMIO_DISPLAY - APMIO_BIOS My apm reports correct info with ACPI kernel as follows. % apm APM version: 1.2 APM Managment: Enabled AC Line status: off-line Battery status: high Remaining battery life: 99% Remaining battery time: 3:18:00 Number of batteries: 1 Battery 0: Battery status: high Remaining battery life: 99% Remaining battery time: 3:18:00 Resume timer: Thu Jan 1 08:59:59 1970 Resume on ring indicator: disabled APM Capacities: unknown Any comments are welcome. I'll commit this coming weekend. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 9:36: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id F221637B401; Wed, 24 Oct 2001 09:35:51 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9OGZpM35317; Wed, 24 Oct 2001 09:35:51 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id A62F939F0; Wed, 24 Oct 2001 09:35:51 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mitsuru IWASAKI Cc: acpi-jp@jp.freebsd.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: ACPI: APM compatibility implementation In-Reply-To: <20011025.012243.71082514.iwasaki@jp.FreeBSD.org> Date: Wed, 24 Oct 2001 09:35:51 -0700 From: Peter Wemm Message-Id: <20011024163551.A62F939F0@overcee.netplex.com.au> 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 Mitsuru IWASAKI wrote: > Hi, > > I've just started implementation of APM compatibility stuff for > FreeBSD/i386. > The goal is to support most APM applications (binary) w/o any changes > on ACPI enabled kernel. > This emulates APM device node interface APIs (mainly ioctl) and > provides APM services for the applications. > > The patches at: > http://people.freebsd.org/~iwasaki/acpi/acpi_compat_apm-20011025.diff This is great news! I look forward to it. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 9:43:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4E1B337B401 for ; Wed, 24 Oct 2001 09:43:21 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id D96D114C2E; Wed, 24 Oct 2001 18:43:19 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: "types" man page From: Dag-Erling Smorgrav Date: 24 Oct 2001 18:43:19 +0200 Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 I've been toying with the idea of creating a "types" man page that lists common scalar and pointer types in FreeBSD (including standard C types). For every type, the man page would indicate: - the name (duh) - what header(s) (if any) to include to define it - width on all supported platforms - signedness - equivalence with other types - appropriate format specifier and cast to use for printf()ing variables of that type portably. What I'm wondering is: 1) does anybody else but me think that this would be a good idea? 2) in what section would such a man page belong? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 9:45:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from squall.waterspout.com (squall.waterspout.com [208.13.56.12]) by hub.freebsd.org (Postfix) with ESMTP id 6BC6737B409 for ; Wed, 24 Oct 2001 09:45:30 -0700 (PDT) Received: by squall.waterspout.com (Postfix, from userid 1050) id 49A499B08; Wed, 24 Oct 2001 11:44:32 -0500 (EST) Date: Wed, 24 Oct 2001 11:44:32 -0500 From: Will Andrews To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: "types" man page Message-ID: <20011024114432.K25747@squall.waterspout.com> Reply-To: Will Andrews Mail-Followup-To: Dag-Erling Smorgrav , arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i 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 On Wed, Oct 24, 2001 at 06:43:19PM +0200, Dag-Erling Smorgrav wrote: > I've been toying with the idea of creating a "types" man page that > lists common scalar and pointer types in FreeBSD (including standard C > types). For every type, the man page would indicate: > > - the name (duh) > - what header(s) (if any) to include to define it > - width on all supported platforms > - signedness > - equivalence with other types > - appropriate format specifier and cast to use for printf()ing > variables of that type portably. > > What I'm wondering is: > > 1) does anybody else but me think that this would be a good idea? Yes. :) > 2) in what section would such a man page belong? 7 or 9? -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 9:48:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 66EA137B403 for ; Wed, 24 Oct 2001 09:48:06 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 4B25614C2E; Wed, 24 Oct 2001 18:48:05 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Will Andrews Cc: arch@freebsd.org Subject: Re: "types" man page References: <20011024114432.K25747@squall.waterspout.com> From: Dag-Erling Smorgrav Date: 24 Oct 2001 18:48:04 +0200 In-Reply-To: <20011024114432.K25747@squall.waterspout.com> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Will Andrews writes: > On Wed, Oct 24, 2001 at 06:43:19PM +0200, Dag-Erling Smorgrav wrote: > > 2) in what section would such a man page belong? > 7 or 9? It's definitely not kernel-only, so I don't think 9 is appropriate; 7 would be a last resort if we can't think of anything better. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 9:51:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from squall.waterspout.com (squall.waterspout.com [208.13.56.12]) by hub.freebsd.org (Postfix) with ESMTP id D6B4B37B403 for ; Wed, 24 Oct 2001 09:51:33 -0700 (PDT) Received: by squall.waterspout.com (Postfix, from userid 1050) id DEA8C9B08; Wed, 24 Oct 2001 11:50:35 -0500 (EST) Date: Wed, 24 Oct 2001 11:50:35 -0500 From: Will Andrews To: Dag-Erling Smorgrav Cc: Will Andrews , arch@freebsd.org Subject: Re: "types" man page Message-ID: <20011024115035.L25747@squall.waterspout.com> Reply-To: Will Andrews Mail-Followup-To: Dag-Erling Smorgrav , Will Andrews , arch@freebsd.org References: <20011024114432.K25747@squall.waterspout.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i 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 On Wed, Oct 24, 2001 at 06:48:04PM +0200, Dag-Erling Smorgrav wrote: > It's definitely not kernel-only, so I don't think 9 is appropriate; 7 > would be a last resort if we can't think of anything better. There *is* nothing better. types(3) maybe, but it's not for library calls. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 10:15:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id ADD3137B401 for ; Wed, 24 Oct 2001 10:15:22 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2364B14C2E; Wed, 24 Oct 2001 19:15:21 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: Re: "types" man page References: From: Dag-Erling Smorgrav Date: 24 Oct 2001 19:15:20 +0200 In-Reply-To: Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Dag-Erling Smorgrav writes: > I've been toying with the idea of creating a "types" man page Oh, wait, there *is* a types page in section 5 - but it's practically a verbatim copy of . Not my idea of useful. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 10:31:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 943E137B406 for ; Wed, 24 Oct 2001 10:31:35 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id f9OHTwt04939; Wed, 24 Oct 2001 20:29:58 +0300 (EEST) (envelope-from ru) Date: Wed, 24 Oct 2001 20:29:58 +0300 From: Ruslan Ermilov To: Dag-Erling Smorgrav Cc: Will Andrews , arch@FreeBSD.ORG Subject: Re: "types" man page Message-ID: <20011024202958.B4437@sunbay.com> References: <20011024114432.K25747@squall.waterspout.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Oct 24, 2001 at 06:48:04PM +0200 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 On Wed, Oct 24, 2001 at 06:48:04PM +0200, Dag-Erling Smorgrav wrote: > Will Andrews writes: > > On Wed, Oct 24, 2001 at 06:43:19PM +0200, Dag-Erling Smorgrav wrote: > > > 2) in what section would such a man page belong? > > 7 or 9? > > It's definitely not kernel-only, so I don't think 9 is appropriate; 7 > would be a last resort if we can't think of anything better. > We already have a precedent for operator(7), so put it into section 7. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 10:49:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 34FB237B401 for ; Wed, 24 Oct 2001 10:49:38 -0700 (PDT) Received: (qmail 56503 invoked from network); 24 Oct 2001 16:53:46 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 Oct 2001 16:53:46 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 24 Oct 2001 09:53:46 -0700 (PDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: "types" man page Cc: arch@freebsd.org, Will Andrews 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 On 24-Oct-01 Dag-Erling Smorgrav wrote: > Will Andrews writes: >> On Wed, Oct 24, 2001 at 06:43:19PM +0200, Dag-Erling Smorgrav wrote: >> > 2) in what section would such a man page belong? >> 7 or 9? > > It's definitely not kernel-only, so I don't think 9 is appropriate; 7 > would be a last resort if we can't think of anything better. 7 is good to me it seems. See operator(7), ascii(7), etc. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 10:52:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7B50637B401; Wed, 24 Oct 2001 10:52:28 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2D2E614C2E; Wed, 24 Oct 2001 19:52:27 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: John Baldwin Cc: arch@freebsd.org, Will Andrews Subject: Re: "types" man page References: From: Dag-Erling Smorgrav Date: 24 Oct 2001 19:52:26 +0200 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 John Baldwin writes: > On 24-Oct-01 Dag-Erling Smorgrav wrote: > > Will Andrews writes: > > > On Wed, Oct 24, 2001 at 06:43:19PM +0200, Dag-Erling Smorgrav wrote: > > > > 2) in what section would such a man page belong? > > > 7 or 9? > > It's definitely not kernel-only, so I don't think 9 is appropriate; 7 > > would be a last resort if we can't think of anything better. > 7 is good to me it seems. See operator(7), ascii(7), etc. Right. What do we do with types(5)? Leave it alone, nuke it, or repo-copy it to types(7)? (I don't see much point in the latter as there would be very little in common between the two) Ruslan, do you have a suggestion for the proper mdoc incantations for a types(7) entry, based on the items I listed in my original mail? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 12: 3:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0951537B405 for ; Wed, 24 Oct 2001 12:03:02 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9OJ2vA46197; Wed, 24 Oct 2001 15:02:57 -0400 (EDT) (envelope-from wollman) Date: Wed, 24 Oct 2001 15:02:57 -0400 (EDT) From: Garrett Wollman Message-Id: <200110241902.f9OJ2vA46197@khavrinen.lcs.mit.edu> To: des@ofug.org Cc: arch@FreeBSD.org Subject: Re: "types" man page In-Reply-To: Organization: MIT Laboratory for Computer Science Cc: 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 In article you write: >I've been toying with the idea of creating a "types" man page that >lists common scalar and pointer types in FreeBSD (including standard C >types). For every type, the man page would indicate: Sounds like a useful endeavor. > - the name (duh) > - what header(s) (if any) to include to define it > - width on all supported platforms Probably a bad idea. Better to specify the range, rather than the width, and do it via the appropriate limit constants, so that people don't make unfortunate assumptions. The only types which would seem to be appropriate to specify the width are the ones which are specified by width (i.e., int8_t et al). In specifying the range one might also note the minimum extrema as specified by any appropriate standard, and any other standards-related constraints (e.g., for all N, intN_t is exactly N bits in width, and if no such exact type is available, intN_t is not defined). > - signedness Implied by the range. > - appropriate format specifier and cast to use for printf()ing > variables of that type portably. This just needs to be stated once: use %jd and (intmax_t) or %ju and (uintmax_t) as appropriate for the signedness, unless it's one of the integral types which has a specifically-defined format (char, short, int, long, long long, size_t, ptrdiff_t, and intmax_t). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 12: 8:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4558837B407 for ; Wed, 24 Oct 2001 12:08:30 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id CD55814C41; Wed, 24 Oct 2001 21:08:28 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: "types" man page References: <200110241902.f9OJ2vA46197@khavrinen.lcs.mit.edu> From: Dag-Erling Smorgrav Date: 24 Oct 2001 21:08:28 +0200 In-Reply-To: <200110241902.f9OJ2vA46197@khavrinen.lcs.mit.edu> Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Garrett Wollman writes: > In article you write: > > - width on all supported platforms > Probably a bad idea. Better to specify the range, rather than the > width, and do it via the appropriate limit constants, so that people > don't make unfortunate assumptions. Ah, yes, I forgot about the limit constants. I'd still like to document the width, though, but it may be more useful to just say "this is of the same width as {int,long,void *} on all platforms". > The only types which would seem > to be appropriate to specify the width are the ones which are > specified by width (i.e., int8_t et al). I think it would be useful to also document the width of the basic C types (char, short, int, long, long long, void *) on the different platforms. > > - appropriate format specifier and cast to use for printf()ing > > variables of that type portably. > This just needs to be stated once: use %jd and (intmax_t) or %ju and > (uintmax_t) as appropriate for the signedness, unless it's one of the > integral types which has a specifically-defined format (char, short, > int, long, long long, size_t, ptrdiff_t, and intmax_t). Our printf(3) man page does not mention a 'j' conversion specifier, and I don't have a copy of C99 at hand. I suppose it's a C99 thing? Does our printf(3) (and our printf(9)) support it? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 12:37:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7D69437B406 for ; Wed, 24 Oct 2001 12:37:10 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9OJaws46582; Wed, 24 Oct 2001 15:36:58 -0400 (EDT) (envelope-from wollman) Date: Wed, 24 Oct 2001 15:36:58 -0400 (EDT) From: Garrett Wollman Message-Id: <200110241936.f9OJaws46582@khavrinen.lcs.mit.edu> To: Dag-Erling Smorgrav Cc: arch@FreeBSD.org Subject: Re: "types" man page In-Reply-To: References: <200110241902.f9OJ2vA46197@khavrinen.lcs.mit.edu> 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 < said: > Our printf(3) man page does not mention a 'j' conversion specifier, > and I don't have a copy of C99 at hand. I suppose it's a C99 thing? > Does our printf(3) (and our printf(9)) support it? I have patches for printf(3), which were posted to the freebsd-standards list; I haven't even looked at the kernel printf, but the changes would be fairly similar. The other new C99 modifiers are `r' (for ptrdiff_t) and `z' (for size_t). C99 also adds the `a' conversion for floating-point numbers, and POSIX/SUS adds the `'' (single close quote) modifier to print using thousands-separators; neither of these are likely to be useful in the kernel. The advice for 4.x should probably say to use `long' almost all the time, except for those types which are documented as `might be longer than long'. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 14:15:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 7DFBD37B403 for ; Wed, 24 Oct 2001 14:15:51 -0700 (PDT) Received: (qmail 33767 invoked from network); 24 Oct 2001 18:11:43 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 Oct 2001 18:11:43 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 24 Oct 2001 11:11:43 -0700 (PDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: "types" man page Cc: Will Andrews , arch@freebsd.org 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 On 24-Oct-01 Dag-Erling Smorgrav wrote: > John Baldwin writes: >> On 24-Oct-01 Dag-Erling Smorgrav wrote: >> > Will Andrews writes: >> > > On Wed, Oct 24, 2001 at 06:43:19PM +0200, Dag-Erling Smorgrav wrote: >> > > > 2) in what section would such a man page belong? >> > > 7 or 9? >> > It's definitely not kernel-only, so I don't think 9 is appropriate; 7 >> > would be a last resort if we can't think of anything better. >> 7 is good to me it seems. See operator(7), ascii(7), etc. > > Right. What do we do with types(5)? Leave it alone, nuke it, or > repo-copy it to types(7)? (I don't see much point in the latter as > there would be very little in common between the two) > > Ruslan, do you have a suggestion for the proper mdoc incantations for > a types(7) entry, based on the items I listed in my original mail? Nuke types(5). Your proposed types(7) will be much more useful, IMO. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 19:14:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 11CE337B405 for ; Wed, 24 Oct 2001 19:14:40 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id B105781D05; Wed, 24 Oct 2001 21:14:34 -0500 (CDT) Date: Wed, 24 Oct 2001 21:14:34 -0500 From: Alfred Perlstein To: Lyndon Nerenberg Cc: arch@freebsd.org Subject: Re: NO_AWK Message-ID: <20011024211434.G15052@elvis.mu.org> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110250153.f9P1rd0H071528@atg.aciworldwide.com>; from lyndon@atg.aciworldwide.com on Wed, Oct 24, 2001 at 07:53:39PM -0600 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 I think this is more of an arch issue. * Lyndon Nerenberg [011024 20:53] wrote: > NOTE: THIS IS A STRAWMAN PROPOSAL! Take it all with a grain of > salt! > > For a long while now I've been running with the bwk version of awk > in preference to the GNU gawk shipped in the base OS. Nothing has > broken as a result of the change, therefore I'm starting to wonder > if a NO_AWK macro for make.conf might not be appropriate. The change > hasn't broken any of my buildworld's since the beginning, although > a naked buildworld without any awk present will certainly fall over > hard. Regardless, I would like to float (and ONLY that) the question > of adding a NO_AWK macro to make.conf. It can be done in a way > that will not break a bootstrap buildworld, yet still allow a > third-party awk to be installed into the production system, and I > have a(n almost complete) set of patches to submit that accomplish > this. So the question is: is there interest? If so, I'll put the > patches up (only against STABLE for now I'm afraid) for review. Is bawk a BSD licensed version of awk? What about replacing gawk with bawk? Any drawbacks? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 19:22: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from atg.aciworldwide.com (h139-142-180-4.gtcust.grouptelecom.net [139.142.180.4]) by hub.freebsd.org (Postfix) with ESMTP id 1A78837B403 for ; Wed, 24 Oct 2001 19:22:04 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id f9P2M30H071765 for ; Wed, 24 Oct 2001 20:22:03 -0600 (MDT) Message-Id: <200110250222.f9P2M30H071765@atg.aciworldwide.com> To: arch@freebsd.org Subject: X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! Organization: ACI Worldwide - Advanced Technology Group Date: Wed, 24 Oct 2001 20:22:03 -0600 From: Lyndon Nerenberg 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 Alfred Perlstein mentioned that these messages might be more appropriate for arch. (I wasn't sure ...) ------- Forwarded Message To: hackers@freebsd.org Subject: GCC/G++ links Date: Wed, 24 Oct 2001 20:17:07 -0600 From: Lyndon Nerenberg [ On a related somewhat anti-GNU thread ... ] 18 months ago we had a conversation on the mailing list about g77 vs. f77 as the canonical command name for the FORTRAN compiler. The crux of the argument was that f77 was the canonical BSD name for the command, and that's what it has been since. There was a related argument as to whether gcc (as a name) should die as well, but the argument was made that too many third party packages would break as a result. For the last year I've been running my systems with the gcc and g++ links to the respective binaries removed, and I haven't seen much break as a result, other than a (very) few ports which were fixed with a quick edit of their Makefile. Meanwhile, it has been useful to install different versions of the GNU C compiler, and in those cases it has also been useful to call them by their real names: gcc and g++. Practical experience shows that cc and gcc can live side-by-side. And also shows that the base OS environment lives well without the GNU naming conventions. Based on this, what do you think about adding a NO_GNU_COMPLER_CMD_LINKS macro to make.conf? If set, if would prevent the linking of cc -> gcc and c++ -> g++, freeing up /usr/local/bin/g* for the site to decide? (And I'm not tied to that horribly long macro name, either.) - --lyndon ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 19:53:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 808F937B405; Wed, 24 Oct 2001 19:53:46 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9P2rjZ138310; Wed, 24 Oct 2001 22:53:45 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011024205654.E3080@FreeBSD.org> References: <200110242107.OAA09339@windsor.research.att.com> <20011024205654.E3080@FreeBSD.org> Date: Wed, 24 Oct 2001 22:53:42 -0400 To: Ade Lovett , Bill Fenner From: Garance A Drosihn Subject: Re: Switch to newer AUTOCONF, and fixing ports Cc: portmgr@FreeBSD.org, arch@FreeBSD.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 Was: cvs commit: ports/devel/automake Makefile distinfo pkg-plist ports/devel/automake/files patch-ab patch-ad At 8:56 PM -0500 10/24/01, Ade Lovett wrote: >On Wed, Oct 24, 2001 at 02:07:35PM -0700, Bill Fenner wrote: >> My experience with newer autoconf a few months ago is that it is not >> backwards-compatible, so we'd need to create a way to have multiple >> autoconf versions installed. > >Ideally, we'd solve this with a separate testbed ports cluster, so we >(portmgr) could drop in the new libtool/autoconf/etc.., get everything >working, then drop it in to the real system. > >Unfortunately, that doesn't appear to be possible right now. > >However, given that 4.4 is out the door, 4.5 is some time away, and 5.x >is just, well, 5.x, perhaps we should lay down a specific tag in the >ports tree (or a firm date) for cvsup updates, flip the switch, then >go through any issues associated with the new autoconf/libtool. > >Sure, initially there's likely to be huge breakage in the ports/ tree, >but I don't see any alternatives, and right now, time is on our side. This seems like a reasonable tactic to me, but I think you need to make sure more people are aware of the proposal (and are comfortable with it) before doing it. Thus, I have changed the subject line on this message, and pointed it to a different combination of mailing lists... This would also allow more people to come up with alternate proposals. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 20: 5:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id CA3EB37B401 for ; Wed, 24 Oct 2001 20:05:08 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9P358o12209; Wed, 24 Oct 2001 20:05:08 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9P35vm00838; Wed, 24 Oct 2001 20:05:57 -0700 (PDT) (envelope-from marcel) Date: Wed, 24 Oct 2001 20:05:57 -0700 From: Marcel Moolenaar To: Lyndon Nerenberg Cc: arch@FreeBSD.ORG Subject: g++ -> c++ and gcc -> cc links [was: Re: ] Message-ID: <20011024200556.A666@dhcp01.pn.xcllnt.net> References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110250222.f9P2M30H071765@atg.aciworldwide.com> User-Agent: Mutt/1.3.21i 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 On Wed, Oct 24, 2001 at 08:22:03PM -0600, Lyndon Nerenberg wrote: > Based on this, what do you think about adding a NO_GNU_COMPLER_CMD_LINKS > macro to make.conf? If set, if would prevent the linking of cc -> > gcc and c++ -> g++, freeing up /usr/local/bin/g* for the site to > decide? (And I'm not tied to that horribly long macro name, either.) I like the idea. Are we in a position to revert the default to not creating the links and add a knob to enable it? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 24 22:27:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 45A2E37B401; Wed, 24 Oct 2001 22:27:41 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 79FB54CE56; Thu, 25 Oct 2001 01:27:40 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id BAA21081; Thu, 25 Oct 2001 01:27:39 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id WAA14597; Wed, 24 Oct 2001 22:27:39 -0700 (PDT) Message-Id: <200110250527.WAA14597@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: drosih@rpi.edu Subject: Re: Switch to newer AUTOCONF, and fixing ports Cc: ade@freebsd.org, portmgr@freebsd.org, arch@freebsd.org References: <200110242107.OAA09339@windsor.research.att.com> <20011024205654.E3080@FreeBSD.org> Date: Wed, 24 Oct 2001 22:27:38 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b 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 I wrote a script that does "make configure" on all USE_AUTOCONF ports with autoconf 2.52 installed; it's only gotten to japanese/esecanna-mod but 48 out of 94 ports have failed. This includes 15 on which it was the "./configure" run itself that failed, so it's only 33 that failed on the autoconf step; the other 15 need more examination to determine if it's my host environment or the new autoconf that caused the failure. (It will try with 2.13.000227 next; presumably those results will be available in the morning.) Don't forget that this 33% failure rate will affect people who use FreeBSD to develop other software too. e.g. tcpdump, libpcap, tcpslice, all fail either autoheader or autoconf with 2.52. It's also non-obvious in some circumstances how to write autoconf scripts that work both with 2.13 and 2.52. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 0:50:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id B363737B405; Thu, 25 Oct 2001 00:50:03 -0700 (PDT) Received: from vega.vega.com (h124.229.dialup.iptcom.net [212.9.229.124]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id KAA47507; Thu, 25 Oct 2001 10:49:58 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id f9P7nRU16963; Thu, 25 Oct 2001 10:49:27 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3BD7C487.E994955B@FreeBSD.org> Date: Thu, 25 Oct 2001 10:51:35 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Bill Fenner Cc: drosih@rpi.edu, ade@FreeBSD.org, portmgr@FreeBSD.org, arch@FreeBSD.org Subject: Re: Switch to newer AUTOCONF, and fixing ports References: <200110242107.OAA09339@windsor.research.att.com> <20011024205654.E3080@FreeBSD.org> <200110250527.WAA14597@windsor.research.att.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit 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 Bill Fenner wrote: > > I wrote a script that does "make configure" on all USE_AUTOCONF ports > with autoconf 2.52 installed; it's only gotten to japanese/esecanna-mod > but 48 out of 94 ports have failed. This includes 15 on which it was > the "./configure" run itself that failed, so it's only 33 that failed > on the autoconf step; the other 15 need more examination to determine > if it's my host environment or the new autoconf that caused the failure. > > (It will try with 2.13.000227 next; presumably those results will be > available in the morning.) > > Don't forget that this 33% failure rate will affect people who use > FreeBSD to develop other software too. e.g. tcpdump, libpcap, tcpslice, > all fail either autoheader or autoconf with 2.52. It's also non-obvious > in some circumstances how to write autoconf scripts that work both with > 2.13 and 2.52. Very representative statistics, thank you Bill. That's why I think that additional automakeXX/autoconfYY representing newest versions is only the one way to go. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 8:40:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 2001F37B415; Thu, 25 Oct 2001 08:39:55 -0700 (PDT) Received: from dialup-209.244.104.103.dial1.sanjose1.level3.net ([209.244.104.103] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15wmbn-0000yw-00; Thu, 25 Oct 2001 08:39:51 -0700 Message-ID: <3BD8327C.A73CF24A@mindspring.com> Date: Thu, 25 Oct 2001 08:40:44 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mitsuru IWASAKI Cc: acpi-jp@jp.freebsd.org, arch@freebsd.org, audit@freebsd.org Subject: Re: ACPI: APM compatibility implementation References: <20011025.012243.71082514.iwasaki@jp.FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Mitsuru IWASAKI wrote: [ ... ] > My apm reports correct info with ACPI kernel as follows. [ ... ] > Remaining battery time: 3:18:00 [ ... ] > Any comments are welcome. I'll commit this coming weekend. Comments: 1) Cool patch! 2) What kind of hardware gives a 3 hour battery life on one battery?!? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 8:52:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 8466537B433; Thu, 25 Oct 2001 08:52:07 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) (authenticated as iwa with CRAM-MD5) by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare) with ESMTP/inet id f9PFq3m87324; Fri, 26 Oct 2001 00:52:03 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Fri, 26 Oct 2001 00:51:58 +0900 (JST) Message-Id: <20011026.005158.71086516.iwasaki@jp.FreeBSD.org> To: arch@freebsd.org Cc: audit@freebsd.org Subject: (was Re: cvs commit: src/sys/modules Makefile src/sys/modules/apm Mak ) From: Mitsuru IWASAKI In-Reply-To: <20011025.231348.92585814.iwasaki@jp.FreeBSD.org> References: <200110250505.f9P55R739324@harmony.village.org> <20011025.231348.92585814.iwasaki@jp.FreeBSD.org> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Hi, I've just make patches for the recent apm module changes. http://people.freebsd.org/~iwasaki/apm/apm_module-20011025.diff The problems I'm tring to solve are; - Apm loadable module cannot inform other kernel components whether apm will be enabled (e.g. i386/isa/clock.c:startrtclock()'s TCS hack). SI_SUB_KLD stuff should be invoked earlier than SI_SUB_CPU. - APM and ACPI cannot co-exist together at the same time according to ACPI spec. They should be enabled exclusively by some sort of arbitration mechanism. - Now that `#ifdef DEV_APM' related code is almost obsolete. Also public apm(4) functions, such as apm_suspend(), cannot be called directly, should be called via abstracted interface. Note that the patches contain exchanging priority of SI_SUB_CPU and SI_SUB_KLD. I already checked dependency of all MOD_LOAD code on cpu_startup() related code (e.g. DELAY) roughly, but I'm not sure if there is no problem. I think that module load event code and kernel linker should not depend on SI_SUB_CPU... Any comments are welcome. I'll commit this early in Nov. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 9: 6:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id E80A537B401; Thu, 25 Oct 2001 09:06:15 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) (authenticated as iwa with CRAM-MD5) by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare/smtpfeed 1.14) with ESMTP/inet id f9PG6Bm90366; Fri, 26 Oct 2001 01:06:11 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Fri, 26 Oct 2001 01:06:08 +0900 (JST) Message-Id: <20011026.010608.97294590.iwasaki@jp.FreeBSD.org> To: tlambert2@mindspring.com Cc: acpi-jp@jp.freebsd.org, arch@freebsd.org, audit@freebsd.org, iwasaki@jp.FreeBSD.org Subject: Re: ACPI: APM compatibility implementation From: Mitsuru IWASAKI In-Reply-To: <3BD8327C.A73CF24A@mindspring.com> References: <20011025.012243.71082514.iwasaki@jp.FreeBSD.org> <3BD8327C.A73CF24A@mindspring.com> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Hi, > > Any comments are welcome. I'll commit this coming weekend. > > Comments: > > 1) Cool patch! Thanks! > 2) What kind of hardware gives a 3 hour battery life on > one battery?!? This one http://www.casio.com/personalpcs/product.cfm?section=17&market=0&product=3917 Bigger battery is like this :) % apm APM version: 1.2 APM Managment: Enabled AC Line status: off-line Battery status: high Remaining battery life: 99% Remaining battery time: 7:01:00 Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 9: 7:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id DD92C37B401 for ; Thu, 25 Oct 2001 09:07:21 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id f9PG76944422; Thu, 25 Oct 2001 19:07:06 +0300 (EEST) (envelope-from ru) Date: Thu, 25 Oct 2001 19:07:06 +0300 From: Ruslan Ermilov To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: "types" man page Message-ID: <20011025190706.D41293@sunbay.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Oct 24, 2001 at 07:52:26PM +0200 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 On Wed, Oct 24, 2001 at 07:52:26PM +0200, Dag-Erling Smorgrav wrote: > John Baldwin writes: > > On 24-Oct-01 Dag-Erling Smorgrav wrote: > > > Will Andrews writes: > > > > On Wed, Oct 24, 2001 at 06:43:19PM +0200, Dag-Erling Smorgrav wrote: > > > > > 2) in what section would such a man page belong? > > > > 7 or 9? > > > It's definitely not kernel-only, so I don't think 9 is appropriate; 7 > > > would be a last resort if we can't think of anything better. > > 7 is good to me it seems. See operator(7), ascii(7), etc. > > Right. What do we do with types(5)? Leave it alone, nuke it, or > repo-copy it to types(7)? (I don't see much point in the latter as > there would be very little in common between the two) > Nuke types(5). Noone is referencing it. > Ruslan, do you have a suggestion for the proper mdoc incantations for > a types(7) entry, based on the items I listed in my original mail? > Just give me an example entry, and I will mark it up as needed. I don't set Mail-Followup-To: header so please Cc: me with the standard group-reply function. Otherwise, such emails may get unnoticed. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 10:30:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id AB7FE37B405; Thu, 25 Oct 2001 10:30:07 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 290D514C2E; Thu, 25 Oct 2001 19:30:06 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Ruslan Ermilov Cc: arch@FreeBSD.ORG Subject: Re: "types" man page References: <20011025190706.D41293@sunbay.com> From: Dag-Erling Smorgrav Date: 25 Oct 2001 19:30:05 +0200 In-Reply-To: <20011025190706.D41293@sunbay.com> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Ruslan Ermilov writes: > On Wed, Oct 24, 2001 at 07:52:26PM +0200, Dag-Erling Smorgrav wrote: > > Ruslan, do you have a suggestion for the proper mdoc incantations for > > a types(7) entry, based on the items I listed in my original mail? > Just give me an example entry, and I will mark it up as needed. pid_t Used to store a process ID. Defined in . Equivalent to a signed int on all platforms. Valid PIDs range from 0 through PID_MAX (defined in ) inclusive. The special value NO_PID (ibid.) is used to indicate an invalid or nonexistent process. The man page should also have a section that describes the relationships between the various headers (including but probably not limited to , , , and ) that either define these types or include other headers which define them. For instance, most programs will want to include or to define pid_t, though or would do. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 12:26:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from atg.aciworldwide.com (h139-142-180-4.gtcust.grouptelecom.net [139.142.180.4]) by hub.freebsd.org (Postfix) with ESMTP id E6A3337B401 for ; Thu, 25 Oct 2001 12:26:30 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id f9PJQT0H077031; Thu, 25 Oct 2001 13:26:30 -0600 (MDT) Message-Id: <200110251926.f9PJQT0H077031@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: NO_AWK In-Reply-To: Message from Alfred Perlstein of "Wed, 24 Oct 2001 21:14:34 CDT." <20011024211434.G15052@elvis.mu.org> Date: Thu, 25 Oct 2001 13:26:29 -0600 From: Lyndon Nerenberg 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 > Is bawk a BSD licensed version of awk? What about replacing gawk with > bawk? Any drawbacks? It's the One True AWK, ala Aho, Weinberger, and Kernighan. See http://plan9.bell-labs.com/cm/cs/awkbook/index.html for details. The license seems compatible (enough) with the BSD license: Copyright (C) Lucent Technologies 1997 All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that the copyright notice and this permission notice and warranty disclaimer appear in supporting documentation, and that the name Lucent Technologies or any of its entities not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. I would certainly prefer to see the reference implementation in the base system. And bugs reported to the authors do appear to get fixed. --lyndon >What about all the people who hoarded tonnes of spam in their bunkers? I hoard spam on my hard drive. When I heard about the coming Y2K worries, I downloaded a lifetime supply from the net. -- Charlie Gibbs in alt.folklore.computers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 12:56:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 665F537B406 for ; Thu, 25 Oct 2001 12:56:20 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id f9PJuFB73998 for ; Thu, 25 Oct 2001 15:56:15 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 25 Oct 2001 15:56:14 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Behavior of select() on pipes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Alfred recently pointed me at some FreeBSD pipe behavior that I was previously unaware of: select() will always return true regarding the readability of a fifo, regardless of whether data is pending on the fifo. He referred to this as "brokenness", which is a diagnosis I tend to accept. However, it turns out to be somewhat more complicated than I thought, witnessed by the extensive discussion on freebsd-bugs, and logged in PR/19871. But to the short of it: it sounds to me like we should modify the behavior of select() to match the more popular (but possibly standards-incompliant) behavior, which allows select to block on the fifo until data is ready (found in Solaris, Linux, et al). Rather than just commit the patch, I thought I'd open myself up for broad flamage. Comments on what to do are welcome. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 13:32:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 686C737B507; Thu, 25 Oct 2001 13:32:10 -0700 (PDT) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA13030; Thu, 25 Oct 2001 14:31:59 -0600 (MDT) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id f9PKVm504839; Thu, 25 Oct 2001 14:31:48 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15320.30388.178781.313461@caddis.yogotech.com> Date: Thu, 25 Oct 2001 14:31:48 -0600 To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI , acpi-jp@jp.FreeBSD.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: ACPI: APM compatibility implementation In-Reply-To: <3BD8327C.A73CF24A@mindspring.com> References: <20011025.012243.71082514.iwasaki@jp.FreeBSD.org> <3BD8327C.A73CF24A@mindspring.com> X-Mailer: VM 6.95 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > [ ... ] > > My apm reports correct info with ACPI kernel as follows. > [ ... ] > > Remaining battery time: 3:18:00 > [ ... ] > > Any comments are welcome. I'll commit this coming weekend. > > Comments: > > 1) Cool patch! > 2) What kind of hardware gives a 3 hour battery life on > one battery?!? Not quite 3 hours, but really close on my ThinkPad. caddis:~ # apm APM version: 1.2 APM Managment: Enabled AC Line status: off-line Battery status: high Remaining battery life: 100% Remaining battery time: 2:50:00 Number of batteries: 2 Battery 0: Battery status: high Remaining battery life: 100% Remaining battery time: 2:50:00 Battery 1: Battery status: not present Resume timer: disabled Resume on ring indicator: disabled APM Capacities: global standby state global suspend state resume timer from suspend 3+ hours is actually common on even newer hardware. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 13:50:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id EF5C037B403 for ; Thu, 25 Oct 2001 13:50:22 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9PKoME08399 for arch@freebsd.org; Thu, 25 Oct 2001 13:50:22 -0700 (PDT) (envelope-from obrien) Date: Thu, 25 Oct 2001 13:50:22 -0700 From: "David O'Brien" To: arch@freebsd.org Subject: import bawk? Re: NO_AWK Message-ID: <20011025135022.A80517@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011024211434.G15052@elvis.mu.org>; from bright@mu.org on Wed, Oct 24, 2001 at 09:14:34PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Wed, Oct 24, 2001 at 09:14:34PM -0500, Alfred Perlstein wrote: > I think this is more of an arch issue. > > * Lyndon Nerenberg [011024 20:53] wrote: > > NOTE: THIS IS A STRAWMAN PROPOSAL! Take it all with a grain of > > salt! > > > For a long while now I've been running with the bwk version of awk > > in preference to the GNU gawk shipped in the base OS. Nothing has ... > Is bawk a BSD licensed version of awk? What about replacing gawk with > bawk? Any drawbacks? bawk is license friendly for us. I've gotten all the gawk'isms out of our tree and have run bawk as my system awk for a while. Want me to just do the vendor import and cut us over? I have not done this yet, because I know bawk can be slower than gawk and didn't want to fight that battle. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 13:52:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id D681C37B405 for ; Thu, 25 Oct 2001 13:52:46 -0700 (PDT) Received: (qmail 6988 invoked from network); 25 Oct 2001 20:52:45 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 25 Oct 2001 20:52:45 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011025135022.A80517@dragon.nuxi.com> Date: Thu, 25 Oct 2001 06:02:08 -0700 (PDT) From: John Baldwin To: arch@freebsd.org Subject: RE: import bawk? Re: NO_AWK 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 On 25-Oct-01 David O'Brien wrote: > On Wed, Oct 24, 2001 at 09:14:34PM -0500, Alfred Perlstein wrote: >> I think this is more of an arch issue. >> >> * Lyndon Nerenberg [011024 20:53] wrote: >> > NOTE: THIS IS A STRAWMAN PROPOSAL! Take it all with a grain of >> > salt! >> >> > For a long while now I've been running with the bwk version of awk >> > in preference to the GNU gawk shipped in the base OS. Nothing has > ... >> Is bawk a BSD licensed version of awk? What about replacing gawk with >> bawk? Any drawbacks? > > bawk is license friendly for us. I've gotten all the gawk'isms out of > our tree and have run bawk as my system awk for a while. Want me to just > do the vendor import and cut us over? > > I have not done this yet, because I know bawk can be slower than gawk and > didn't want to fight that battle. How much slower? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 13:52:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id DB28737B401 for ; Thu, 25 Oct 2001 13:52:55 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9PKqn708419; Thu, 25 Oct 2001 13:52:49 -0700 (PDT) (envelope-from obrien) Date: Thu, 25 Oct 2001 13:52:49 -0700 From: "David O'Brien" To: Lyndon Nerenberg Cc: arch@freebsd.org Subject: Re: your mail Message-ID: <20011025135249.B80517@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110250222.f9P2M30H071765@atg.aciworldwide.com>; from lyndon@atg.aciworldwide.com on Wed, Oct 24, 2001 at 08:22:03PM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Wed, Oct 24, 2001 at 08:22:03PM -0600, Lyndon Nerenberg wrote: > There was a > related argument as to whether gcc (as a name) should die as well, > but the argument was made that too many third party packages would > break as a result. NO! There is zero need for this change, and yes many 3rd part things will break. > Meanwhile, it has been useful to install different versions of the > GNU C compiler, and in those cases it has also been useful to call > them by their real names: gcc and g++. It also works fine to have them named what I have made them in the ports. Your email sounds like you have a special (or unusual) need that you are trying to force upon all of us. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 14:12: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 9CE6137B406; Thu, 25 Oct 2001 14:12:00 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 6FF2681D06; Thu, 25 Oct 2001 16:12:00 -0500 (CDT) Date: Thu, 25 Oct 2001 16:12:00 -0500 From: Alfred Perlstein To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: Behavior of select() on pipes Message-ID: <20011025161200.N15052@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Thu, Oct 25, 2001 at 03:56:14PM -0400 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 * Robert Watson [011025 14:56] wrote: > > Alfred recently pointed me at some FreeBSD pipe behavior that I was > previously unaware of: select() will always return true regarding the > readability of a fifo, regardless of whether data is pending on the fifo. > He referred to this as "brokenness", which is a diagnosis I tend to > accept. However, it turns out to be somewhat more complicated than I > thought, witnessed by the extensive discussion on freebsd-bugs, and logged > in PR/19871. But to the short of it: it sounds to me like we should > modify the behavior of select() to match the more popular (but possibly > standards-incompliant) behavior, which allows select to block on the fifo > until data is ready (found in Solaris, Linux, et al). Rather than just > commit the patch, I thought I'd open myself up for broad flamage. > Comments on what to do are welcome. If the patch safely brings us into compatibility with both Linux and Solaris it's a no-brainer, just put it in, however if it puts FreeBSD into some other 'mode' I think it deserves further discussion. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 14:13:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id BEBBF37B401 for ; Thu, 25 Oct 2001 14:13:14 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 8ED2681D06; Thu, 25 Oct 2001 16:13:14 -0500 (CDT) Date: Thu, 25 Oct 2001 16:13:14 -0500 From: Alfred Perlstein To: arch@freebsd.org Cc: Lyndon Nerenberg Subject: Re: your mail Message-ID: <20011025161314.O15052@elvis.mu.org> References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> <20011025135249.B80517@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025135249.B80517@dragon.nuxi.com>; from dev-null@NUXI.com on Thu, Oct 25, 2001 at 01:52:49PM -0700 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 * David O'Brien [011025 15:53] wrote: > On Wed, Oct 24, 2001 at 08:22:03PM -0600, Lyndon Nerenberg wrote: > > There was a > > related argument as to whether gcc (as a name) should die as well, > > but the argument was made that too many third party packages would > > break as a result. > > NO! There is zero need for this change, and yes many 3rd part things > will break. > > > Meanwhile, it has been useful to install different versions of the > > GNU C compiler, and in those cases it has also been useful to call > > them by their real names: gcc and g++. > > It also works fine to have them named what I have made them in the ports. > > Your email sounds like you have a special (or unusual) need that you are > trying to force upon all of us. To me it makes sense, 'cc' is the system compiler, and anything else is what it is, yes, we have gcc installed, but what will/would happen if we were to switch base compilers? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 14:19:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 650D537B401 for ; Thu, 25 Oct 2001 14:19:34 -0700 (PDT) Received: (qmail 42600 invoked from network); 25 Oct 2001 21:19:33 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 25 Oct 2001 21:19:33 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011025161314.O15052@elvis.mu.org> Date: Thu, 25 Oct 2001 14:19:32 -0700 (PDT) From: John Baldwin To: Alfred Perlstein Subject: Re: your mail Cc: Lyndon Nerenberg , arch@freebsd.org 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 On 25-Oct-01 Alfred Perlstein wrote: > * David O'Brien [011025 15:53] wrote: >> On Wed, Oct 24, 2001 at 08:22:03PM -0600, Lyndon Nerenberg wrote: >> > There was a >> > related argument as to whether gcc (as a name) should die as well, >> > but the argument was made that too many third party packages would >> > break as a result. >> >> NO! There is zero need for this change, and yes many 3rd part things >> will break. >> >> > Meanwhile, it has been useful to install different versions of the >> > GNU C compiler, and in those cases it has also been useful to call >> > them by their real names: gcc and g++. >> >> It also works fine to have them named what I have made them in the ports. >> >> Your email sounds like you have a special (or unusual) need that you are >> trying to force upon all of us. > > To me it makes sense, 'cc' is the system compiler, and anything > else is what it is, yes, we have gcc installed, but what will/would > happen if we were to switch base compilers? We can still keep the gcc names because, well, they are gcc. :) However, calling the system compiler 'cc' makes perfect sense, and it shouldn't hurt to do this. In fact, since Lyndon is just asking for a switch to do it (and not one that will be on by default) there should be no harm in adding such a switch. Remember, we aren't supposed to set policy here. :) The base system should not depend on the 'gcc' name, so having an _option_ to not use the g* names shouldn't be something to get upset about. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 15:14:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AD0A537B405 for ; Thu, 25 Oct 2001 15:14:55 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id f9PMEjB76030; Thu, 25 Oct 2001 18:14:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 25 Oct 2001 18:14:45 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein Cc: arch@FreeBSD.org Subject: Re: Behavior of select() on pipes In-Reply-To: <20011025161200.N15052@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 25 Oct 2001, Alfred Perlstein wrote: > * Robert Watson [011025 14:56] wrote: > > > > Alfred recently pointed me at some FreeBSD pipe behavior that I was > > previously unaware of: select() will always return true regarding the > > readability of a fifo, regardless of whether data is pending on the fifo. > > He referred to this as "brokenness", which is a diagnosis I tend to > > accept. However, it turns out to be somewhat more complicated than I > > thought, witnessed by the extensive discussion on freebsd-bugs, and logged > > in PR/19871. But to the short of it: it sounds to me like we should > > modify the behavior of select() to match the more popular (but possibly > > standards-incompliant) behavior, which allows select to block on the fifo > > until data is ready (found in Solaris, Linux, et al). Rather than just > > commit the patch, I thought I'd open myself up for broad flamage. > > Comments on what to do are welcome. > > If the patch safely brings us into compatibility with both Linux and > Solaris it's a no-brainer, just put it in, however if it puts FreeBSD > into some other 'mode' I think it deserves further discussion. My understanding, from my reading of the PR, is that it does so. However, I'm not familiar with the sections of the standards describing fifos, and was hoping for input from those that would. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 16: 0:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 4441437B401 for ; Thu, 25 Oct 2001 16:00:18 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 72C914CE16 for ; Thu, 25 Oct 2001 19:00:14 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA05542 for ; Thu, 25 Oct 2001 19:00:13 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA27628; Thu, 25 Oct 2001 16:00:13 -0700 (PDT) Message-Id: <200110252300.QAA27628@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: arch@freebsd.org Subject: Re: import bawk? Re: NO_AWK References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> Date: Thu, 25 Oct 2001 16:00:13 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b 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 >bawk is license friendly for us. "without fee" is license friendly for us? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 16:36:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id C5EA737B409 for ; Thu, 25 Oct 2001 16:36:02 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9PNa2M41082 for ; Thu, 25 Oct 2001 16:36:02 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 587C63808 for ; Thu, 25 Oct 2001 16:36:02 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: arch@freebsd.org Subject: 64 bit times revisited.. Date: Thu, 25 Oct 2001 16:36:02 -0700 From: Peter Wemm Message-Id: <20011025233602.587C63808@overcee.netplex.com.au> 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 I know I am going to regret this, but the subject came up again where we got burnet by code that "knows" that time_t is a long, and on machines where long != int, this can get ugly when pointers to long and int are mixed up. It was pointed out that *all* the linux 64 bit arches have 64 bit time_t, so obviously it isn't too hard a problem to solve. I did a scan around our tree looking for things where size of time_t matters. Here's what I found initially: sizeof(time_t) exposed: /etc/pwd.db (pw_change, pw_expire) /var/run/utmp (ut_time) /var/log/lastlog (ll_time) dump/restore tape format (spcl. c_data, d_ddate, etc) /var/db/acct (ac_btime - begin time of a process) notable exceptions where times are explicitly sized: ufs inode format (has ufs_time_t == 32 bits explicitly) nfs (uses 32 bit timestamps in v3, and 64 bit on v4 (I believe)). notable exeptions 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) There are a couple of other interesting things on 64 bit machines (alpha, ia64, sparc64) as things stand right now: struct timeval { long tv_sec; /* 64 bit */ long tv_usec; /* 64 bit */ } struct timespec { time_t tv_sec; /* 32 bit */ long tv_nsec; /* 64 bit */ } Anywhere that struct timeval or struct timespec are exposed presently leads to a 32 / 64 bit incompatability. Also, struct timespec has structure alignment issues so that tv_sec actually uses 64 bits of space anyway in order to preserve the 64 bit alignment of tv_nsec. This stuff is well exposed in struct stat. I was (foolishly?) optimistic in wondering if we may be able to share the freebsd system call sysvec tables stuff between i386 and ia64 applications but sadly, it is not to be. There are too many "long"'s in enough syscalls to break it. And then we have to swab struct stat and a bunch of other things. The same thing will apply to x86-64 which runs both 32 and 64 bit compiled applications which will have a different sizeof(long). I am starting to wonder now if we're doing ourselves a long-term disservice by locking time_t into 32 bit. People may say "but we can resolve it closer to the time", but they also said that about 32 bit file sizes. Look at the trouble that Linux is still having with applications and libraries due to the transition from off_t being 32 bits to 64 bits, and recall how little pain we had because 4.4BSD did it right from the start. I am also wondering if we should reconsider time_t == int32_t given that we have at least two new 64 bit platforms coming online as we speak, and now is the next best chance that we have to make a clean break like 4.4BSD did with file sizes. Intel are planning on the IA64 architecture to last something like 20-30 years before it runs out of steam.. that is awfully close to Y2038. Maybe I'm being optomistic in thinking that FreeBSD or even unix will be around in another 20 years, but I'd sure like to think that we dont help contribute to our demise by not having a long term solution to the time_t wraparound problem. Possible solutions: 1) Do nothing. (This worked well for Y2K consultants between 1995-2000) 2) Use 64 bit time_t on new 64 bit platforms. 2) Switch to 64 bit time_t on 64 bit platforms. 3) Switch to 64 bit time_t on everything including i386. Pros/cons for each: 1) Pro: No effort required. Con: As time goes by, we're going to see more and more time calculation bugs and eventually shooting ourselves in the foot. 2) Pro: Clean break, no cost for new platforms. Con: There are still some hard coded 32 bit timestamps around that will eventually require magic number / version / format bumps. eg: UFS inodes etc. Dual-mode cpus (ia64, x86-64) may have fun. Different types (int on alpha, long in x86-64, ia64 and sparc64, int on ppc and i386 - printf format hell). Doesn't solve hard coded timestamp sizes in exposed disk and wire structures. 3) Pro: Clean break for new platforms. We could even use the same type (long) across the board, including i386, and that saves trouble with printf etc. (%ld everywhere) Con: This hurts the alpha, our only established 64 bit platform. Doesn't solve dual-mode cpu problems Doesn't solve hard coded timestamp sizes in exposed disk and wire structures. 4) Pro: All wire and on-disk formats mentioning time_t will be compatable across the entire freebsd range. The Pentium21 (to be released in year 2021) will be Y2038 safe. :-) Con: Break i386 *.o compatability. We would be subjecting ourselves to the same sort of pain that the rest of the unix world went through (and is still going through with the 64 bit filesize transition). Doesn't solve things like "int32_t start_time;" in exposed disk and on-the-wire structures. Printf format hell (%qd on i386, %ld on the 64 bit platforms) where it causes real screwups if there is a mistake. Personally, I feel that we should (at the least) do #2 (64 bit times for new 64 bit platforms), and maybe even #3 (change the alpha too) if we have the willpower. The alpha problem can be solved with version bumps etc and keep old syscall interfaces around like we do with compat_43. #3 has the advantage of being able to use a constant printf format and have the same type everywhere (long). I'm somewhat disappointed that we didn't make a clean break with time_t == long on the alpha. Even DECpaq realized that was a mistake and tried to switch to 64 bit time_t in Tru64 v5.0. We still have to deal with some on-disk and on-wire exposure: /etc/pwd.db (pw_change, pw_expire) This can be fixed fairly painlessly. The .db files have typed records so we can create new record types and generate old ones for compatability with 32 bit applications. The old record type could be changed from time_t to int32_t pw_change etc. Only pwd_mkdb ever writes to this, so it can be done in a safe, upward compatable fashion so that old apps will continue to run for years. /var/run/utmp (ut_time) /var/log/lastlog (ll_time) ouch! we learned the hard way on this stuff with the change in size of login names etc. We could explicitly size these timestamps while waiting for the next reason to change the format or switching to a real utmp API (and changing the timestamps at the same time). dump/restore tape format (spcl. c_data, d_ddate, etc) create a new record type for 64 bit timestamps and switch the current record specification to int32_t (thats all that is in UFS right now after all). /var/db/acct (ac_btime - begin time of a process) Only system tools read this. This should be harmless to change at any time, but should probably be switched to int32_t for now. In summary.. I think we've been shortsighted and made a mistake. I dont believe it is too late to fix - in fact, we have some excellent opportunities to fix it coming up. My way of thinking is that we should take the opportunity, but the bigger question is whether or not to disturb the alpha.. I suspect we can, and that we can make it painless enough for what the (relatively few) people are using them for. So.. What do people think? Let the bikeshedding begin... Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 16:43:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id DB36A37B406; Thu, 25 Oct 2001 16:43:25 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 22BD01E00D; Thu, 25 Oct 2001 19:43:20 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA06028; Thu, 25 Oct 2001 19:43:19 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA28072; Thu, 25 Oct 2001 16:43:18 -0700 (PDT) Message-Id: <200110252343.QAA28072@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rwatson@freebsd.org Subject: Re: Behavior of select() on pipes Cc: bright@mu.org, arch@freebsd.org Date: Thu, 25 Oct 2001 16:43:18 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b 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 IEEE Std 1003.1-200x says, about select: A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. and about read: When attempting to read from an empty pipe or FIFO: * If no process has the pipe open for writing, read( ) shall return 0 to indicate end-of-file. This combination says to me that select() should consider a FIFO with no writers to be readable. This makes sense when it's been open and the writer closes it, as you need to read the EOF, but doesn't make as much sense when it hasn't been opened for write yet. Perhaps we can carefully interpret "an empty .. FIFO" to exclude the time before the first writer opens it. Maybe during that time it's not empty, it's untenanted. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 17: 6: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 91FEA37B406 for ; Thu, 25 Oct 2001 17:06:03 -0700 (PDT) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id f9Q05vQ05273; Thu, 25 Oct 2001 17:06:01 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200110260006.f9Q05vQ05273@beastie.mckusick.com> To: Peter Wemm Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG 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 17:05:57 -0700 From: Kirk McKusick 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 I vote for option (3), 64-bit time_t for all 64 bit architectures. I would go along with option (4) provided that the change-over came with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. The change from 4.X to 5.0 will have enough other things going on that I do not think that adding the time_t change would cause a lot more pain provided that old dump tapes and log files could be read. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 17:20:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1840137B406 for ; Thu, 25 Oct 2001 17:20:29 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9Q0KQR63759; Thu, 25 Oct 2001 20:20:26 -0400 (EDT) (envelope-from wollman) Date: Thu, 25 Oct 2001 20:20:26 -0400 (EDT) From: Garrett Wollman Message-Id: <200110260020.f9Q0KQR63759@khavrinen.lcs.mit.edu> To: peter@wemm.org Cc: arch@FreeBSD.org Subject: Re: 64 bit times revisited.. In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au> Organization: MIT Laboratory for Computer Science Cc: 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 In article <20011025233602.587C63808@overcee.netplex.com.au> you write: >Possible solutions: >1) Do nothing. (This worked well for Y2K consultants between 1995-2000) >2) Use 64 bit time_t on new 64 bit platforms. >2) Switch to 64 bit time_t on 64 bit platforms. >3) Switch to 64 bit time_t on everything including i386. V) Do what the Large File Summit did for off_t: define 32- and 64-bit versions of every interface that uses a time_t, and let a preprocessor macro switch between them. Allow five years for migration, at which point the 32-bit option is removed. On new platforms (regardless of native word size), use the 64-bit versions. Meanwhile, start deploying a new inode format with 64-bit times. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 17:28:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id CC9B037B403 for ; Thu, 25 Oct 2001 17:28:16 -0700 (PDT) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f9Q0SBH04756; Thu, 25 Oct 2001 17:28:11 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 25 Oct 2001 17:28:11 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 > It was pointed out that *all* the linux 64 bit arches have 64 bit time_t, > so obviously it isn't too hard a problem to solve. No, that's not a fair comparison as linux pays for such ease by making very little committment to true machine/arch independent code. > .. > notable exceptions where times are explicitly sized: > ufs inode format (has ufs_time_t == 32 bits explicitly) > nfs (uses 32 bit timestamps in v3, and 64 bit on v4 (I believe)). v4 isn't real yet, and we don't do well with v3 yet, so I wouldn't worry a lot about this yet. Can we assume that up until the year 2038 or so we can always stuff a value in a current time_t back into a 32 bit time value? Is this true for all values which we wish to really consider as values that are external representations that are portable? If so, then we should just stick to 32 bits for this. > I am starting to wonder now if we're doing ourselves a long-term disservice > by locking time_t into 32 bit. People may say "but we can resolve it closer > to the time", but they also said that about 32 bit file sizes. Look at the > trouble that Linux is still having with applications and libraries due to > the transition from off_t being 32 bits to 64 bits, and recall how little > pain we had because 4.4BSD did it right from the start. Again, I'm not sure this is a fair comparison. There's a real need to exceed a 4GB space with file offsets. But unless time starts running faster than the current one second per second I guess I don't see what the problem is between now and 2038. Oh, all right, 2028- give some slop. Now- if you're talking about time values where we carry current time stamps around to be measured to the nanosecond- yes, *that's* going to be required. I raised this with Bosko recently about the time stamp stuff he's doing- it's getting somewhat pointless to not have at minimum 64 bit counters for that kind of resolution. >.. > unix will be around in another 20 years, but I'd sure like to think that > we dont help contribute to our demise by not having a long term solution > to the time_t wraparound problem. That's a long time away. Frankly, anything that is a exposed to multiple architectures should be restricted to the *minimum* usable size for the next 20 years- the costs of changeover are high now, and make the platforms with the smaller natural word size pay high penalties for very little gain. So, I would suggest going the other way- break alpha so that time_t is 32 bits on alpha. There *is* no installed base for alpha (effectively). This is stated more as an extreme position the other way, just to see what it tastes like. The pros of this is that then we have a clear mandate to make all of the platforms the same standard size to promote interoperability. Otherwise I think #3 is the best. I don't really think #4 is the right thing to do because it will probably really break i386 and make things bloated, Kirk's opinions not withstanding. And, btw, I think Garrett's idea is neat, but way overengineered. FWIW. Oh- yeah- this is too big of an issue to really turn into a bikeshed discussion- this is more like "shall we build a 5000 megawatt nuclear power plant next month?".. Thanks for bringing it up. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 17:39: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id CB93237B405; Thu, 25 Oct 2001 17:39:02 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 924C581D05; Thu, 25 Oct 2001 19:38:57 -0500 (CDT) Date: Thu, 25 Oct 2001 19:38:57 -0500 From: Alfred Perlstein To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: Behavior of select() on pipes Message-ID: <20011025193857.U15052@elvis.mu.org> References: <20011025161200.N15052@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Thu, Oct 25, 2001 at 06:14:45PM -0400 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 * Robert Watson [011025 17:14] wrote: > > On Thu, 25 Oct 2001, Alfred Perlstein wrote: > > > * Robert Watson [011025 14:56] wrote: > > > > > > Alfred recently pointed me at some FreeBSD pipe behavior that I was > > > previously unaware of: select() will always return true regarding the > > > readability of a fifo, regardless of whether data is pending on the fifo. > > > He referred to this as "brokenness", which is a diagnosis I tend to > > > accept. However, it turns out to be somewhat more complicated than I > > > thought, witnessed by the extensive discussion on freebsd-bugs, and logged > > > in PR/19871. But to the short of it: it sounds to me like we should > > > modify the behavior of select() to match the more popular (but possibly > > > standards-incompliant) behavior, which allows select to block on the fifo > > > until data is ready (found in Solaris, Linux, et al). Rather than just > > > commit the patch, I thought I'd open myself up for broad flamage. > > > Comments on what to do are welcome. > > > > If the patch safely brings us into compatibility with both Linux and > > Solaris it's a no-brainer, just put it in, however if it puts FreeBSD > > into some other 'mode' I think it deserves further discussion. > > My understanding, from my reading of the PR, is that it does so. However, > I'm not familiar with the sections of the standards describing fifos, and > was hoping for input from those that would. I'll look at it, I have a couple of non freebsd hosts (blech) to try it on. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 17:48: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CD8FE37B401 for ; Thu, 25 Oct 2001 17:48:00 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9Q0lsf16513; Thu, 25 Oct 2001 17:47:54 -0700 (PDT) (envelope-from dillon) Date: Thu, 25 Oct 2001 17:47:54 -0700 (PDT) From: Matthew Dillon Message-Id: <200110260047.f9Q0lsf16513@apollo.backplane.com> To: Kirk McKusick Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> 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 :I vote for option (3), 64-bit time_t for all 64 bit architectures. :I would go along with option (4) provided that the change-over came :with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. :The change from 4.X to 5.0 will have enough other things going on :that I do not think that adding the time_t change would cause a :lot more pain provided that old dump tapes and log files could :be read. : : Kirk McKusick I agree completely. 64 bit time_t for all 64 bit archs, and frankly I would also like to see a 64 bit time_t for 5.x on 32 bit archs... lets get the pain over and done with now rather then later. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 17:49:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 7884B37B401 for ; Thu, 25 Oct 2001 17:49:25 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 73CA881D05; Thu, 25 Oct 2001 19:49:25 -0500 (CDT) Date: Thu, 25 Oct 2001 19:49:25 -0500 From: Alfred Perlstein To: Matthew Dillon Cc: Kirk McKusick , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011025194925.X15052@elvis.mu.org> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110260047.f9Q0lsf16513@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Oct 25, 2001 at 05:47:54PM -0700 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 * Matthew Dillon [011025 19:48] wrote: > > :I vote for option (3), 64-bit time_t for all 64 bit architectures. > :I would go along with option (4) provided that the change-over came > :with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > :The change from 4.X to 5.0 will have enough other things going on > :that I do not think that adding the time_t change would cause a > :lot more pain provided that old dump tapes and log files could > :be read. > : > : Kirk McKusick > > I agree completely. 64 bit time_t for all 64 bit archs, and > frankly I would also like to see a 64 bit time_t for 5.x on 32 > bit archs... lets get the pain over and done with now rather then > later. *nod* onward upward! -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 17:59: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id 9ED6E37B403 for ; Thu, 25 Oct 2001 17:59:04 -0700 (PDT) Received: (qmail 47001 invoked by uid 1000); 26 Oct 2001 00:59:03 -0000 Date: Thu, 25 Oct 2001 20:59:03 -0400 From: Joe Abley To: arch@freebsd.org Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011025205902.G11022@buffoon.automagic.org> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011025135022.A80517@dragon.nuxi.com> User-Agent: Mutt/1.3.22.1i 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 On Thu, Oct 25, 2001 at 01:50:22PM -0700, David O'Brien wrote: > On Wed, Oct 24, 2001 at 09:14:34PM -0500, Alfred Perlstein wrote: > > Is bawk a BSD licensed version of awk? What about replacing gawk with > > bawk? Any drawbacks? > > bawk is license friendly for us. I've gotten all the gawk'isms out of > our tree and have run bawk as my system awk for a while. Want me to just > do the vendor import and cut us over? > > I have not done this yet, because I know bawk can be slower than gawk and > didn't want to fight that battle. gawk has features that bawk doesn't have. I write a lot of awk (more than is healthy) and I know I am guilty of using gawkisms. Hence, at the least, a large HEADS UP may be worthwhile ahead of such a change to warn morons like me that their scripts may be about to start breaking. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 18: 1:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id C28F137B407 for ; Thu, 25 Oct 2001 18:01:10 -0700 (PDT) Received: (qmail 19487 invoked from network); 26 Oct 2001 01:01:08 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2001 01:01:08 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200110260006.f9Q05vQ05273@beastie.mckusick.com> Date: Thu, 25 Oct 2001 18:01:07 -0700 (PDT) From: John Baldwin To: Kirk McKusick Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG, Peter Wemm 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 On 26-Oct-01 Kirk McKusick wrote: > I vote for option (3), 64-bit time_t for all 64 bit architectures. > I would go along with option (4) provided that the change-over came > with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > The change from 4.X to 5.0 will have enough other things going on > that I do not think that adding the time_t change would cause a > lot more pain provided that old dump tapes and log files could > be read. Agreed. Also, we could hack the compat libraries shipped with 5.x for Alpha and i386 to dink with the syscall arguments where necessary to allow legacy applications to run. Well, dynamically linked ones. :( I suppose we could use an alternate syscall table like we do for linux, svr4, etc. for compat on i386 and alpha for old binaries. (This is for the 4) case and possibly 3)). > Kirk McKusick -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message 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 From owner-freebsd-arch Thu Oct 25 18:39:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id EA6F637B406; Thu, 25 Oct 2001 18:39:15 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9Q1dF117032; Thu, 25 Oct 2001 18:39:15 -0700 (PDT) (envelope-from dillon) Date: Thu, 25 Oct 2001 18:39:15 -0700 (PDT) From: Matthew Dillon Message-Id: <200110260139.f9Q1dF117032@apollo.backplane.com> To: John Baldwin Cc: Kirk McKusick , arch@FreeBSD.ORG, Peter Wemm Subject: Re: 64 bit times revisited.. References: 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 :Agreed. Also, we could hack the compat libraries shipped with 5.x for Alpha :and i386 to dink with the syscall arguments where necessary to allow legacy :applications to run. Well, dynamically linked ones. :( I suppose we could use :an alternate syscall table like we do for linux, svr4, etc. for compat on i386 :and alpha for old binaries. (This is for the 4) case and possibly 3)). : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ We do a major-rev change on the libraries and reassign syscall numbers for functions that mess with time_t's, leaving compat routines in the kernel for the old syscall numbers (just as we did for things like stat()). We then remove all int/long assumptions from utility and library code. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 18:44:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.noos.fr (verlaine.noos.net [212.198.2.73]) by hub.freebsd.org (Postfix) with ESMTP id C81DC37B401 for ; Thu, 25 Oct 2001 18:44:34 -0700 (PDT) Received: (qmail 365182 invoked by uid 0); 26 Oct 2001 01:44:29 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.73 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Oct 2001 01:44:29 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id f9Q1iRA50747; Fri, 26 Oct 2001 03:44:27 +0200 (CEST) (envelope-from root) Message-Id: <200110260144.f9Q1iRA50747@gits.dyndns.org> Subject: Re: import bawk? Re: NO_AWK In-Reply-To: <20011025205902.G11022@buffoon.automagic.org> To: Joe Abley Date: Fri, 26 Oct 2001 03:44:25 +0200 (CEST) Cc: arch@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL94c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 Joe Abley wrote: > On Thu, Oct 25, 2001 at 01:50:22PM -0700, David O'Brien wrote: > > On Wed, Oct 24, 2001 at 09:14:34PM -0500, Alfred Perlstein wrote: > > > Is bawk a BSD licensed version of awk? What about replacing gawk with > > > bawk? Any drawbacks? > > > > bawk is license friendly for us. I've gotten all the gawk'isms out of > > our tree and have run bawk as my system awk for a while. Want me to just > > do the vendor import and cut us over? > > > > I have not done this yet, because I know bawk can be slower than gawk and > > didn't want to fight that battle. > > gawk has features that bawk doesn't have. that may be considered as a problem. you could think you write portable stuffs until you try to use them on another platform. having a "true" awk w/o any extensions may help a lot in god practice. > I write a lot of awk (more than is healthy) and I know I am guilty > of using gawkisms. Hence, at the least, a large HEADS UP may be > worthwhile ahead of such a change to warn morons like me that their > scripts may be about to start breaking. you always have the choice to use gawk from ports... Cyrille. -- Cyrille Lefevre mailto:clefevre@citeweb.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 18:49:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 5F2B337B403 for ; Thu, 25 Oct 2001 18:49:54 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9Q1naH04637; Thu, 25 Oct 2001 18:49:36 -0700 (PDT) (envelope-from obrien) Date: Thu, 25 Oct 2001 18:49:36 -0700 From: "David O'Brien" To: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011025184936.A4609@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG Mail-Followup-To: arch@freebsd.org References: <20011025233602.587C63808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Thu, Oct 25, 2001 at 05:28:11PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Thu, Oct 25, 2001 at 05:28:11PM -0700, Matthew Jacob wrote: > > It was pointed out that *all* the linux 64 bit arches have 64 bit time_t, > > so obviously it isn't too hard a problem to solve. > > No, that's not a fair comparison as linux pays for such ease by making > very little committment to true machine/arch independent code. I want to chime in and agree with Matt here. My earlier pushes in this area was to make make FreeBSD consistent. FreeBSD on one platform should be as alike every other FreeBSD platform as we can make it. Thus I want time_t to be the same size on every FreeBSD platform so that time wrap-arounds happen in the same way on the most popular platform (read i386) which gets a lot of testing and defines what is FreeBSD in behavior, and the Alpha platform (which at times seems to only have a hand-full of users). As we get more platforms, we are only going to have more of the problem of FreeBSD really only being well used on one of our offered architectures. -- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 18:55:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4188637B406 for ; Thu, 25 Oct 2001 18:55:21 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9Q1tKo04718; Thu, 25 Oct 2001 18:55:20 -0700 (PDT) (envelope-from obrien) Date: Thu, 25 Oct 2001 18:55:20 -0700 From: "David O'Brien" To: Peter Wemm Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. Message-ID: <20011025185520.B4609@dragon.nuxi.com> Reply-To: arch@freebsd.org Mail-Followup-To: arch@freebsd.org References: <20011025233602.587C63808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au>; from peter@wemm.org on Thu, Oct 25, 2001 at 04:36:02PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Thu, Oct 25, 2001 at 04:36:02PM -0700, Peter Wemm wrote: > I'm somewhat disappointed that we didn't make a clean break with time_t > == long on the alpha. Even DECpaq realized that was a mistake and tried > to switch to 64 bit time_t in Tru64 v5.0. Our Alpha porting happened pre-Tru64 v5.0, and our osf1 compat layer predates it also. Given that, a 32-bit type made sense. And as Andrew said before, DEC Alpha OSF/1 defined that a 64-bit platform looks like. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 19: 1:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 051EE37B401; Thu, 25 Oct 2001 19:01:17 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9Q21G104827; Thu, 25 Oct 2001 19:01:16 -0700 (PDT) (envelope-from obrien) Date: Thu, 25 Oct 2001 19:01:16 -0700 From: "David O'Brien" To: John Baldwin Cc: Lyndon Nerenberg , arch@FreeBSD.org Subject: Re: your mail Message-ID: <20011025190116.C4609@dragon.nuxi.com> Reply-To: arch@FreeBSD.org Mail-Followup-To: arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Oct 25, 2001 at 02:19:32PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Thu, Oct 25, 2001 at 02:19:32PM -0700, John Baldwin wrote: > We can still keep the gcc names because, well, they are gcc. :) However, > calling the system compiler 'cc' makes perfect sense, and it shouldn't > hurt to do this. We all *ready* call the system compiler `cc'. So I don't understand what you are saying. > In fact, since Lyndon is just asking for a switch to do it (and not > one that will be on by default) there should be no harm in adding such a > switch. Other than a messier Makefile for what I see as a very rare corner case. > Remember, we aren't supposed to set policy here. :) The base system > should not depend on the 'gcc' name, so having an _option_ to not use > the g* names shouldn't be something to get upset about. We aren't setting policy. Like it or not, our system compiler is `gcc'. Also like it or not `gcc' is the most prolific compiler in all of history. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 19: 3:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 03C6C37B403; Thu, 25 Oct 2001 19:03:42 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9Q23fb04847; Thu, 25 Oct 2001 19:03:41 -0700 (PDT) (envelope-from obrien) Date: Thu, 25 Oct 2001 19:03:41 -0700 From: "David O'Brien" To: Maxim Sobolev Cc: Bill Fenner , drosih@rpi.edu, ade@FreeBSD.org, portmgr@FreeBSD.org, arch@FreeBSD.org Subject: Re: Switch to newer AUTOCONF, and fixing ports Message-ID: <20011025190341.D4609@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200110242107.OAA09339@windsor.research.att.com> <20011024205654.E3080@FreeBSD.org> <200110250527.WAA14597@windsor.research.att.com> <3BD7C487.E994955B@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD7C487.E994955B@FreeBSD.org>; from sobomax@FreeBSD.org on Thu, Oct 25, 2001 at 10:51:35AM +0300 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Thu, Oct 25, 2001 at 10:51:35AM +0300, Maxim Sobolev wrote: > Very representative statistics, thank you Bill. That's why I > think that additional automakeXX/autoconfYY representing > newest versions is only the one way to go. WRONG!! Adding automakeXX/autoconfYY representing _OLD_ versions. The naked program name should be the latest released we have in ports. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 19: 5:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id D537737B403; Thu, 25 Oct 2001 19:05:13 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9Q25Br04878; Thu, 25 Oct 2001 19:05:11 -0700 (PDT) (envelope-from obrien) Date: Thu, 25 Oct 2001 19:05:10 -0700 From: "David O'Brien" To: Bill Fenner Cc: drosih@rpi.edu, ade@freebsd.org, portmgr@freebsd.org, arch@freebsd.org Subject: Re: Switch to newer AUTOCONF, and fixing ports Message-ID: <20011025190510.E4609@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200110242107.OAA09339@windsor.research.att.com> <20011024205654.E3080@FreeBSD.org> <200110250527.WAA14597@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110250527.WAA14597@windsor.research.att.com>; from fenner@research.att.com on Wed, Oct 24, 2001 at 10:27:38PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Wed, Oct 24, 2001 at 10:27:38PM -0700, Bill Fenner wrote: > Don't forget that this 33% failure rate will affect people who use > FreeBSD to develop other software too. e.g. tcpdump, libpcap, tcpslice, > all fail either autoheader or autoconf with 2.52. It's also non-obvious > in some circumstances how to write autoconf scripts that work both with > 2.13 and 2.52. I do not thing being able to write scripts that work with either version is a goal the autoconf developers have put forward. A project has to settle on one version and have all its developers use that version. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 19:16:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id 2F78937B403 for ; Thu, 25 Oct 2001 19:16:28 -0700 (PDT) Received: (qmail 47840 invoked by uid 1000); 26 Oct 2001 02:16:27 -0000 Date: Thu, 25 Oct 2001 22:16:27 -0400 From: Joe Abley To: Cyrille Lefevre Cc: arch@freebsd.org Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011025221626.I11022@buffoon.automagic.org> References: <20011025205902.G11022@buffoon.automagic.org> <200110260144.f9Q1iRA50747@gits.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110260144.f9Q1iRA50747@gits.dyndns.org> User-Agent: Mutt/1.3.22.1i 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 On Fri, Oct 26, 2001 at 03:44:25AM +0200, Cyrille Lefevre wrote: > Joe Abley wrote: > > On Thu, Oct 25, 2001 at 01:50:22PM -0700, David O'Brien wrote: > > > On Wed, Oct 24, 2001 at 09:14:34PM -0500, Alfred Perlstein wrote: > > > > Is bawk a BSD licensed version of awk? What about replacing gawk with > > > > bawk? Any drawbacks? > > > > > > bawk is license friendly for us. I've gotten all the gawk'isms out of > > > our tree and have run bawk as my system awk for a while. Want me to just > > > do the vendor import and cut us over? > > > > > > I have not done this yet, because I know bawk can be slower than gawk and > > > didn't want to fight that battle. > > > > gawk has features that bawk doesn't have. > > that may be considered as a problem. you could think you write > portable stuffs until you try to use them on another platform. > having a "true" awk w/o any extensions may help a lot in god > practice. I agree. > > I write a lot of awk (more than is healthy) and I know I am guilty > > of using gawkisms. Hence, at the least, a large HEADS UP may be > > worthwhile ahead of such a change to warn morons like me that their > > scripts may be about to start breaking. > > you always have the choice to use gawk from ports... Absolutely. I agree, and I would be happy to banish gawkisms from /usr/bin/awk. I'm just saying there is an existing population of scripts which begin "#!/usr/bin/awk -f" that may break, and that for that reason appropriate warnings should be given. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 21:23:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 7673837B405 for ; Thu, 25 Oct 2001 21:23:12 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9Q4QxO98773; Fri, 26 Oct 2001 00:26:59 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Oct 2001 00:26:59 -0400 From: Mike Barcroft To: Bill Fenner Cc: arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011026002659.H93553@coffee.q9media.com> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110252300.QAA27628@windsor.research.att.com>; from fenner@research.att.com on Thu, Oct 25, 2001 at 04:00:13PM -0700 Organization: The FreeBSD Project 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 Bill Fenner writes: > >bawk is license friendly for us. > > "without fee" is license friendly for us? The way I read it, the "without fee" applies to the "permission", not the "any purpose." That is, they grant you permission to use it for any purpose and don't charge you a fee. They don't require your uses of it be not-for-profit. It looks like a reworded 3-clause BSD license to me. :) Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 21:46: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 6B83C37B403 for ; Thu, 25 Oct 2001 21:46:05 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9Q4nj298811; Fri, 26 Oct 2001 00:49:45 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Oct 2001 00:49:45 -0400 From: Mike Barcroft To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026004945.I93553@coffee.q9media.com> References: <20011025233602.587C63808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au>; from peter@wemm.org on Thu, Oct 25, 2001 at 04:36:02PM -0700 Organization: The FreeBSD Project 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 Peter Wemm writes: > 4) Pro: > All wire and on-disk formats mentioning time_t will be compatable > across the entire freebsd range. > The Pentium21 (to be released in year 2021) will be Y2038 safe. :-) > Con: > Break i386 *.o compatability. We would be subjecting ourselves to > the same sort of pain that the rest of the unix world went through > (and is still going through with the 64 bit filesize transition). > Doesn't solve things like "int32_t start_time;" in exposed disk and > on-the-wire structures. > Printf format hell (%qd on i386, %ld on the 64 bit platforms) where > it causes real screwups if there is a mistake. I vote for 4. The issue with printf(9) could be solved by using the new C99 type intmax_t (which defines the largest possible integer type available) and printf() counterpart %j. Ofcourse this might be a problem if we port to a 128 bit processor. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 21:58: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id E8E6837B403 for ; Thu, 25 Oct 2001 21:58:00 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9Q51iJ98845; Fri, 26 Oct 2001 01:01:44 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Oct 2001 01:01:43 -0400 From: Mike Barcroft To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011026010143.J93553@coffee.q9media.com> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011025135022.A80517@dragon.nuxi.com>; from dev-null@NUXI.com on Thu, Oct 25, 2001 at 01:50:22PM -0700 Organization: The FreeBSD Project 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 David O'Brien writes: > On Wed, Oct 24, 2001 at 09:14:34PM -0500, Alfred Perlstein wrote: > > Is bawk a BSD licensed version of awk? What about replacing gawk with > > bawk? Any drawbacks? > > bawk is license friendly for us. I've gotten all the gawk'isms out of > our tree and have run bawk as my system awk for a while. Want me to just > do the vendor import and cut us over? I'm in favour of this, as a -CURRENT only thang. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 22:12:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from c527597-a.cstvl1.sfba.home.com (c527597-a.cstvl1.sfba.home.com [24.176.204.87]) by hub.freebsd.org (Postfix) with ESMTP id 0ECE237B405; Thu, 25 Oct 2001 22:12:16 -0700 (PDT) Received: (from bmah@localhost) by c527597-a.cstvl1.sfba.home.com (8.11.6/8.11.6) id f9Q5CFS40443; Thu, 25 Oct 2001 22:12:15 -0700 (PDT) (envelope-from bmah) Message-Id: <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mike Barcroft Cc: Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK In-Reply-To: <20011026002659.H93553@coffee.q9media.com> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> Comments: In-reply-to Mike Barcroft message dated "Fri, 26 Oct 2001 00:26:59 -0400." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1469206625P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 25 Oct 2001 22:12:15 -0700 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 --==_Exmh_1469206625P Content-Type: text/plain; charset=us-ascii If memory serves me right, Mike Barcroft wrote: > Bill Fenner writes: > > >bawk is license friendly for us. > > > > "without fee" is license friendly for us? > > The way I read it, the "without fee" applies to the "permission", not > the "any purpose." That is, they grant you permission to use it for > any purpose and don't charge you a fee. They don't require your uses > of it be not-for-profit. > > It looks like a reworded 3-clause BSD license to me. :) Rather than us guessing at the meaning (which I feel *is* rather ambiguous), would it make sense for someone to request clarification from some suitable representative of Lucent, telling them exactly what the plans are and asking if they're compatible with the license? The Web page has a pointer to Brian Kernighan...I'm pretty sure he'd know the answer. :-) Bruce. --==_Exmh_1469206625P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE72PCv2MoxcVugUsMRAuDbAKDZhIpURRAjjQ/siTgdcGM0rqkCpQCgk4El MpVgeanqKV3DFVEAune0SjA= =XalA -----END PGP SIGNATURE----- --==_Exmh_1469206625P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 22:54:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 14D6337B406 for ; Thu, 25 Oct 2001 22:54:15 -0700 (PDT) Received: (qmail 11264 invoked from network); 26 Oct 2001 05:53:57 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2001 05:53:57 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011025190116.C4609@dragon.nuxi.com> Date: Thu, 25 Oct 2001 22:53:51 -0700 (PDT) From: John Baldwin To: "David O'Brien" Subject: Re: your mail Cc: arch@FreeBSD.org, Lyndon Nerenberg 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 On 26-Oct-01 David O'Brien wrote: > On Thu, Oct 25, 2001 at 02:19:32PM -0700, John Baldwin wrote: >> In fact, since Lyndon is just asking for a switch to do it (and not >> one that will be on by default) there should be no harm in adding such a >> switch. > > Other than a messier Makefile for what I see as a very rare corner case. Messy? Index: Makefile =================================================================== RCS file: /usr/cvs/src/gnu/usr.bin/cc/cc/Makefile,v retrieving revision 1.24 diff -u -r1.24 Makefile --- Makefile 27 Mar 2001 14:58:37 -0000 1.24 +++ Makefile 26 Oct 2001 05:46:19 -0000 @@ -9,7 +9,10 @@ SRCS= gcc.c gccspec.c NOSHARED?=yes -LINKS= ${BINDIR}/cc ${BINDIR}/gcc +LINKS= ${BINDIR}/cc +.ifdef(GCC_NAMES) +LINKS+= ${BINDIR}/gcc +.endif MLINKS= gcc.1 cc.1 gcc.1 c++.1 gcc.1 g++.1 gcc.1 CC.1 CFLAGS+= -DDEFAULT_TARGET_VERSION=\"$(version)\" Doesn't look but so bad to me. They aren't in vendor code, so it's not like they have to be redone constantly for upgrades. It's just simple changes to the bmake Makefiles. I'll come up with the diff if you want. Granted, this doesn't fix the manpages which might be slightly harder. (Manpage would need to be installed as cc.1, and then you conditionalize the MLINKS line similary for the g*.1 links. Not too terribly difficult, but slightly more complicated than the above.) >> Remember, we aren't supposed to set policy here. :) The base system >> should not depend on the 'gcc' name, so having an _option_ to not use >> the g* names shouldn't be something to get upset about. > > We aren't setting policy. Like it or not, our system compiler is `gcc'. > Also like it or not `gcc' is the most prolific compiler in all of history. Err. Read those two sentences back to back. "We aren't setting policy. Like it or not..." Sounds like setting policy and users be damned to me. It seems more like you just don't like the idea since you wouldn't use it and thus have decided to take it as a personal issue. It's just hardlinks to a few binaries here, not the end of the world. > -- > -- David (obrien@FreeBSD.org) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 23:29: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1084237B405 for ; Thu, 25 Oct 2001 23:29:02 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9Q6SEh23017; Fri, 26 Oct 2001 08:28:25 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) 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: Fri, 26 Oct 2001 08:28:14 +0200 Message-ID: <23015.1004077694@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <20011025233602.587C63808@overcee.netplex.com.au>, Peter Wemm writes : >There are a couple of other interesting things on 64 bit machines >(alpha, ia64, sparc64) as things stand right now: > struct timeval { > long tv_sec; /* 64 bit */ > long tv_usec; /* 64 bit */ > } > struct timespec { > time_t tv_sec; /* 32 bit */ > long tv_nsec; /* 64 bit */ > } I find it rather obvious that all 64bit archs should have 64bit time_t's. I'm not particular interested in what size we give the 32bit archs, but acknowledge that at some point they will have to change and 5.0 i as good a chance as any. BUT, i would like to point out a problem in the other direction: We are now routinely talking about GHz+ CPUs, but struct timespec can only do nanosecond resolution and arithmetic on timeval and timespec sux badly. I would like for us to introduce a new format of timestamps: struct time$something { time_t tx_sec; /* 64bit */ uint_64_t tx_fsec; /* binary fraction of second */; } If we have access to a int_128_t type, we could instead simply define a scalar type 128 bits wide, resolved in 1/(1<<64) seconds (.0542E-18 == .0542 attoseconds) This format would be faster for any kind of arithmetic, including inside the timecounter code, and it would have sufficient bits in both directions for any forseeable future. Converting from a time$something to a timespec or timeval is done by multiplication and shift: tv_usec = (tx_fsec * (1000000 << 32)) >> 96; tv_nsec = (tx_fsec * (1000000000 << 32)) >> 96; Which is much cheaper cpu-wise than the gunk we currently have to deal with all over the place: if (tv_nsec > 1000000000) { tv_nsec -= 1000000000; tv_sec++; } if (tv_nsec < 0) { tv_nsec += 1000000000; tv_sec--; } Comments ? -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 25 23:39:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 128D937B401; Thu, 25 Oct 2001 23:39:30 -0700 (PDT) Received: from dialup-209.245.128.14.dial1.sanjose1.level3.net ([209.245.128.14] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15x0eP-0002zT-00; Thu, 25 Oct 2001 23:39:29 -0700 Message-ID: <3BD90556.1A64F524@mindspring.com> Date: Thu, 25 Oct 2001 23:40:22 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: "types" man page References: <20011025190706.D41293@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Ruslan Ermilov wrote: > Nuke types(5). Noone is referencing it. The Single UNIX Specification has a types(5) man page for the sys/types.h header file. Removing it from section 5 is probably a bad idea... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0: 3:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 5567437B403 for ; Fri, 26 Oct 2001 00:03:43 -0700 (PDT) Received: from dialup-209.245.128.14.dial1.sanjose1.level3.net ([209.245.128.14] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15x11p-0001WY-00; Fri, 26 Oct 2001 00:03:42 -0700 Message-ID: <3BD90AFF.4BBEC004@mindspring.com> Date: Fri, 26 Oct 2001 00:04:31 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kirk McKusick Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Kirk McKusick wrote: > > I vote for option (3), 64-bit time_t for all 64 bit architectures. > I would go along with option (4) provided that the change-over came > with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > The change from 4.X to 5.0 will have enough other things going on > that I do not think that adding the time_t change would cause a > lot more pain provided that old dump tapes and log files could > be read. Since we have you here... The 32 bit reserve time in the on disk time, which was taken over for the "nanotime", was reserved for a 64 bit time_t in the UFS on disk structures, right? It seems to me that if higher resolution is needed on mtime for things like "make", that it should be limited to mtime _only_, and that that could take a different, single reserve field, instead of taking up 32 bits for every time value. So again: the 64 bit reserved area adjacent to the times was intended for a 64 bit second counter, right? This has been a long standing annoyance to me (my systems have run this way since late 1995) that this apparently reserved area for handling exactly this problem was coopted to make really fast systems not rebuild object files. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0: 7:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 51E2037B403; Fri, 26 Oct 2001 00:07:38 -0700 (PDT) Received: from dialup-209.245.128.14.dial1.sanjose1.level3.net ([209.245.128.14] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15x15d-00035d-00; Fri, 26 Oct 2001 00:07:37 -0700 Message-ID: <3BD90BEE.20B08DC@mindspring.com> Date: Fri, 26 Oct 2001 00:08:30 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: John Baldwin , Kirk McKusick , arch@FreeBSD.ORG, Peter Wemm Subject: Re: 64 bit times revisited.. References: <200110260139.f9Q1dF117032@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Matthew Dillon wrote: > We do a major-rev change on the libraries and reassign syscall numbers > for functions that mess with time_t's, leaving compat routines in the > kernel for the old syscall numbers (just as we did for things like > stat()). We then remove all int/long assumptions from utility and > library code. BSDI wanted to cut us off on system call numbers, with a very small reserve of available numbers for FreeBSD future expansion. What was the resolution on this issue? It seems that if we agreed to the boundaries they wanted at the time, that we would not be able to take this approach (it was a ridiculously small number, I remember, around 10...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0:10:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 1F2AE37B405 for ; Fri, 26 Oct 2001 00:10:35 -0700 (PDT) Received: from dialup-209.245.128.14.dial1.sanjose1.level3.net ([209.245.128.14] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15x18U-0004CB-00; Fri, 26 Oct 2001 00:10:34 -0700 Message-ID: <3BD90CA0.E4F60C0E@mindspring.com> Date: Fri, 26 Oct 2001 00:11:28 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.ORG Cc: Peter Wemm Subject: Re: 64 bit times revisited.. References: <20011025233602.587C63808@overcee.netplex.com.au> <20011025184936.A4609@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 David O'Brien wrote: > I want to chime in and agree with Matt here. > My earlier pushes in this area was to make make FreeBSD consistent. > FreeBSD on one platform should be as alike every other FreeBSD platform > as we can make it. > > Thus I want time_t to be the same size on every FreeBSD platform so that > time wrap-arounds happen in the same way on the most popular platform > (read i386) which gets a lot of testing and defines what is FreeBSD in > behavior, and the Alpha platform (which at times seems to only have a > hand-full of users). As we get more platforms, we are only going to have > more of the problem of FreeBSD really only being well used on one of our > offered architectures. Add me to the "me too" camp. The most interesting use of this would be to have a user space x86 emulator (like one of the two in ports) that mmaps x86 executables, and then interprets them, handling traps by trapping to native system calls on the local system. There's a lot of x86 commercial software that won't run on Alpha/SPARC/MIPS that could be accessed this way... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0:12:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 06B3537B406 for ; Fri, 26 Oct 2001 00:12:10 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA08900; Fri, 26 Oct 2001 01:21:45 -0700 (PDT) Date: Fri, 26 Oct 2001 01:21:44 -0700 (PDT) From: Julian Elischer To: Peter Wemm Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 25 Oct 2001, Peter Wemm wrote: > I know I am going to regret this, but the subject came up again where > we got burnet by code that "knows" that time_t is a long, and on machines > where long != int, this can get ugly when pointers to long and int are > mixed up. > > It was pointed out that *all* the linux 64 bit arches have 64 bit time_t, > so obviously it isn't too hard a problem to solve. > > I did a scan around our tree looking for things where size of time_t > matters. Here's what I found initially: > > sizeof(time_t) exposed: > /etc/pwd.db (pw_change, pw_expire) > /var/run/utmp (ut_time) > /var/log/lastlog (ll_time) > dump/restore tape format (spcl. c_data, d_ddate, etc) > /var/db/acct (ac_btime - begin time of a process) > > notable exceptions where times are explicitly sized: > ufs inode format (has ufs_time_t == 32 bits explicitly) ufs has enough room to fix this.. there has been a field defined in the on disk inode for nanosecs in each of the time values... if we take the lowest 8 bits of that field and re-assign it to be the highest 8 bits of the seconds, then we have time accuracy down to microseconds still and we expand file times by a factor of 256 (which is all of recorded history plus some) we just always set those bits to 0 for the next 37 years and we don;t really lose time resolution and we gain compatibility with the future.. nothing these days has nonosecond resolution there anyhow.... > > 3) Switch to 64 bit time_t on everything including i386. my vote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0:12:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 6BA0537B406 for ; Fri, 26 Oct 2001 00:12:16 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA08948; Fri, 26 Oct 2001 01:39:22 -0700 (PDT) Date: Fri, 26 Oct 2001 01:39:20 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Kirk McKusick , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <3BD90AFF.4BBEC004@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 26 Oct 2001, Terry Lambert wrote: > Kirk McKusick wrote: > > > > I vote for option (3), 64-bit time_t for all 64 bit architectures. > > I would go along with option (4) provided that the change-over came > > with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > > The change from 4.X to 5.0 will have enough other things going on > > that I do not think that adding the time_t change would cause a > > lot more pain provided that old dump tapes and log files could > > be read. > > Since we have you here... > > The 32 bit reserve time in the on disk time, which was taken > over for the "nanotime", was reserved for a 64 bit time_t in > the UFS on disk structures, right? > you can split the field and have enough of both.... > It seems to me that if higher resolution is needed on mtime > for things like "make", that it should be limited to mtime > _only_, and that that could take a different, single reserve > field, instead of taking up 32 bits for every time value. > > So again: the 64 bit reserved area adjacent to the times was > intended for a 64 bit second counter, right? > > This has been a long standing annoyance to me (my systems > have run this way since late 1995) that this apparently > reserved area for handling exactly this problem was coopted > to make really fast systems not rebuild object files. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0:16:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-3.dsl.lsan03.pacbell.net [63.207.60.3]) by hub.freebsd.org (Postfix) with ESMTP id DB29037B405; Fri, 26 Oct 2001 00:16:47 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 70E1466B0E; Fri, 26 Oct 2001 00:16:47 -0700 (PDT) Date: Fri, 26 Oct 2001 00:16:47 -0700 From: Kris Kennaway To: Mike Barcroft Cc: David O'Brien , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011026001647.A49188@xor.obsecurity.org> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <20011026010143.J93553@coffee.q9media.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011026010143.J93553@coffee.q9media.com>; from mike@FreeBSD.ORG on Fri, Oct 26, 2001 at 01:01:43AM -0400 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 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2001 at 01:01:43AM -0400, Mike Barcroft wrote: > David O'Brien writes: > > On Wed, Oct 24, 2001 at 09:14:34PM -0500, Alfred Perlstein wrote: > > > Is bawk a BSD licensed version of awk? What about replacing gawk with > > > bawk? Any drawbacks? > >=20 > > bawk is license friendly for us. I've gotten all the gawk'isms out of > > our tree and have run bawk as my system awk for a while. Want me to ju= st > > do the vendor import and cut us over? >=20 > I'm in favour of this, as a -CURRENT only thang. Me too (modulo clarification of the license). One less GNU tool dependency in FreeBSD. Kris --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE72Q3eWry0BWjoQKURAgnhAKDR5pC7ogV3zmjYsa3794H0ZnKd0QCg8HEo xR/1WFbtNKe3GXOVD4nIvZA= =S2l2 -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0:18:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id DDC3937B403 for ; Fri, 26 Oct 2001 00:18:43 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9Q7I7h24139; Fri, 26 Oct 2001 09:18:08 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 01:21:44 PDT." Date: Fri, 26 Oct 2001 09:18:07 +0200 Message-ID: <24137.1004080687@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message , Jul ian Elischer writes: >ufs has enough room to fix this.. >there has been a field defined in the on disk inode for nanosecs >in each of the time values... >if we take the lowest 8 bits of that field and re-assign it to be >the highest 8 bits of the seconds, then we have time accuracy down to >microseconds still and we expand file times by a factor >of 256 (which is all of recorded history plus some) > >we just always set those bits to 0 for the next 37 years and we don;t >really lose time resolution and we gain compatibility with the future.. >nothing these days has nonosecond resolution there anyhow.... "640K is enough for anybody" "There is no harm in tobacco" "Of course I'll respect you in the morning" etc etc Your proposal would leave us with quarter-microsecond resolution, and I'm pretty sure I can beat that to pulp in the next 10 years on a RAM disk... There is no harm in having to run a rev on the UFS/FFS on-disk format, when you hav 37 years to complete it. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0:43:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.noos.fr (racine.noos.net [212.198.2.71]) by hub.freebsd.org (Postfix) with ESMTP id 532F737B407 for ; Fri, 26 Oct 2001 00:43:13 -0700 (PDT) Received: (qmail 11082022 invoked by uid 0); 26 Oct 2001 07:36:37 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.71 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Oct 2001 07:36:37 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id f9Q7abh65198; Fri, 26 Oct 2001 09:36:37 +0200 (CEST) (envelope-from root) Message-Id: <200110260736.f9Q7abh65198@gits.dyndns.org> Subject: Re: import bawk? Re: NO_AWK In-Reply-To: <20011025221626.I11022@buffoon.automagic.org> To: Joe Abley Date: Fri, 26 Oct 2001 09:36:37 +0200 (CEST) Cc: arch@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL94c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 Joe Abley wrote: > On Fri, Oct 26, 2001 at 03:44:25AM +0200, Cyrille Lefevre wrote: [snip] > > you always have the choice to use gawk from ports... > > Absolutely. I agree, and I would be happy to banish gawkisms from > /usr/bin/awk. I'm just saying there is an existing population of > scripts which begin "#!/usr/bin/awk -f" that may break, and that > for that reason appropriate warnings should be given. forgot about that ! Cyrille. -- Cyrille Lefevre mailto:clefevre@citeweb.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 0:56:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 9ED9037B41B for ; Fri, 26 Oct 2001 00:56:44 -0700 (PDT) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id f9Q7uVQ06967; Fri, 26 Oct 2001 00:56:31 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200110260756.f9Q7uVQ06967@beastie.mckusick.com> To: tlambert2@mindspring.com Subject: Re: 64 bit times revisited.. Cc: Peter Wemm , arch@FreeBSD.ORG In-Reply-To: Your message of "Fri, 26 Oct 2001 00:04:31 PDT." <3BD90AFF.4BBEC004@mindspring.com> Date: Fri, 26 Oct 2001 00:56:31 -0700 From: Kirk McKusick 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 I left the spare space in the inode in anticipation of 64-bit time_t values. Unfortunately, it was coopted for other purposes. I am working on a major revision to UFS that uses 64-bit block pointers. I intend to put in 64-bit times as part of the revision. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 1: 9:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id F283D37B403 for ; Fri, 26 Oct 2001 01:09:29 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9Q88Jh25039; Fri, 26 Oct 2001 10:08:19 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Kirk McKusick Cc: tlambert2@mindspring.com, Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 00:56:31 PDT." <200110260756.f9Q7uVQ06967@beastie.mckusick.com> Date: Fri, 26 Oct 2001 10:08:19 +0200 Message-ID: <25037.1004083699@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110260756.f9Q7uVQ06967@beastie.mckusick.com>, Kirk McKusick writ es: >I left the spare space in the inode in anticipation of 64-bit >time_t values. Unfortunately, it was coopted for other purposes. >I am working on a major revision to UFS that uses 64-bit block >pointers. I intend to put in 64-bit times as part of the revision. Please see my other email on this, you should use 64+64 bit format. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 1:51:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 1598737B40A for ; Fri, 26 Oct 2001 01:51:12 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id f9Q8o5p48497; Fri, 26 Oct 2001 11:50:05 +0300 (EEST) (envelope-from ru) Date: Fri, 26 Oct 2001 11:50:04 +0300 From: Ruslan Ermilov To: Terry Lambert Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: "types" man page Message-ID: <20011026115004.A48208@sunbay.com> References: <20011025190706.D41293@sunbay.com> <3BD90556.1A64F524@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD90556.1A64F524@mindspring.com>; from tlambert2@mindspring.com on Thu, Oct 25, 2001 at 11:40:22PM -0700 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 On Thu, Oct 25, 2001 at 11:40:22PM -0700, Terry Lambert wrote: > Ruslan Ermilov wrote: > > Nuke types(5). Noone is referencing it. > > The Single UNIX Specification has a types(5) man page for the > sys/types.h header file. > > Removing it from section 5 is probably a bad idea... > Then (we need to) update it to match reality. :-) Otherwise it's useless. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 2:45:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 7508437B405; Fri, 26 Oct 2001 02:45:42 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9Q9jgx12839; Fri, 26 Oct 2001 02:45:42 -0700 (PDT) (envelope-from obrien) Date: Fri, 26 Oct 2001 02:45:42 -0700 From: "David O'Brien" To: John Baldwin Cc: arch@FreeBSD.org, Lyndon Nerenberg Subject: Re: your mail Message-ID: <20011026024542.B12708@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20011025190116.C4609@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Oct 25, 2001 at 10:53:51PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Thu, Oct 25, 2001 at 10:53:51PM -0700, John Baldwin wrote: > Messy? Yes, needless junk. > Index: Makefile > =================================================================== > RCS file: /usr/cvs/src/gnu/usr.bin/cc/cc/Makefile,v > retrieving revision 1.24 > diff -u -r1.24 Makefile > --- Makefile 27 Mar 2001 14:58:37 -0000 1.24 > +++ Makefile 26 Oct 2001 05:46:19 -0000 > @@ -9,7 +9,10 @@ > SRCS= gcc.c gccspec.c > NOSHARED?=yes > > -LINKS= ${BINDIR}/cc ${BINDIR}/gcc > +LINKS= ${BINDIR}/cc > +.ifdef(GCC_NAMES) > +LINKS+= ${BINDIR}/gcc > +.endif uh... +.if !defined(NO_GCC_LINK) if anything. Again, other than some utopian idea of a clensed spirit, what do you hope to acomplish with this change? > It seems more like you just don't like the idea since > you wouldn't use it and thus have decided to take it as a personal > issue. It's just hardlinks to a few binaries here, not the end of the > world. I will direct all the freebsd-questions email on "where did gcc" go to you. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 2:48:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (sentinel.office1.bg [217.75.129.210]) by hub.freebsd.org (Postfix) with SMTP id CCB5B37B403 for ; Fri, 26 Oct 2001 02:47:13 -0700 (PDT) Received: (qmail 53326 invoked by uid 1000); 26 Oct 2001 09:44:52 -0000 Date: Fri, 26 Oct 2001 12:44:52 +0300 From: Peter Pentchev To: Cyrille Lefevre Cc: Joe Abley , arch@freebsd.org Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011026124451.B33751@straylight.oblivion.bg> Mail-Followup-To: Cyrille Lefevre , Joe Abley , arch@freebsd.org References: <20011025221626.I11022@buffoon.automagic.org> <200110260736.f9Q7abh65198@gits.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110260736.f9Q7abh65198@gits.dyndns.org>; from clefevre@citeweb.net on Fri, Oct 26, 2001 at 09:36:37AM +0200 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 On Fri, Oct 26, 2001 at 09:36:37AM +0200, Cyrille Lefevre wrote: > Joe Abley wrote: > > On Fri, Oct 26, 2001 at 03:44:25AM +0200, Cyrille Lefevre wrote: > [snip] > > > you always have the choice to use gawk from ports... > > > > Absolutely. I agree, and I would be happy to banish gawkisms from > > /usr/bin/awk. I'm just saying there is an existing population of > > scripts which begin "#!/usr/bin/awk -f" that may break, and that > > for that reason appropriate warnings should be given. > > forgot about that ! This would be easily fixed with NO_AWK and a devel/gawk port which could be built with PREFIX=/, no? G'luck, Peter -- This sentence contradicts itself - or rather - well, no, actually it doesn't! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 3: 9:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id CDBBE37B406 for ; Fri, 26 Oct 2001 03:09:41 -0700 (PDT) Received: (qmail 84392 invoked from network); 26 Oct 2001 10:09:32 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2001 10:09:32 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011026024542.B12708@dragon.nuxi.com> Date: Fri, 26 Oct 2001 03:09:28 -0700 (PDT) From: John Baldwin To: "David O'Brien" Subject: Re: your mail Cc: Lyndon Nerenberg , arch@FreeBSD.org 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 On 26-Oct-01 David O'Brien wrote: > On Thu, Oct 25, 2001 at 10:53:51PM -0700, John Baldwin wrote: >> Messy? > > Yes, needless junk. Well, it's not that important either way. However, this seems to be the only actual reason you have for opposing this. I can buy this one but not the rest of your arguments. However, you may decide however you wish. >> Index: Makefile >> =================================================================== >> RCS file: /usr/cvs/src/gnu/usr.bin/cc/cc/Makefile,v >> retrieving revision 1.24 >> diff -u -r1.24 Makefile >> --- Makefile 27 Mar 2001 14:58:37 -0000 1.24 >> +++ Makefile 26 Oct 2001 05:46:19 -0000 >> @@ -9,7 +9,10 @@ >> SRCS= gcc.c gccspec.c >> NOSHARED?=yes >> >> -LINKS= ${BINDIR}/cc ${BINDIR}/gcc >> +LINKS= ${BINDIR}/cc >> +.ifdef(GCC_NAMES) >> +LINKS+= ${BINDIR}/gcc >> +.endif > > uh... > +.if !defined(NO_GCC_LINK) > if anything. The name was just a suggestion, I'm sure a better one can be found. > Again, other than some utopian idea of a clensed spirit, what do you hope > to acomplish with this change? As already stated, some people find this useful. Just because you don't find it useful doesn't mean it isn't useful to others. >> It seems more like you just don't like the idea since >> you wouldn't use it and thus have decided to take it as a personal >> issue. It's just hardlinks to a few binaries here, not the end of the >> world. > > I will direct all the freebsd-questions email on "where did gcc" go to > you. Err. Since this would be an _optional_ toggle that defaults to having the gcc names by default, there will be no flood of email on freebsd-questions. It's just like how we have a NO_AWK knob. You use it if you know what you are doing, but it hasn't resulted in lots of "gee, where is awk?" mails to freebsd-questions. > -- > -- David (obrien@FreeBSD.org) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 3:11:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (sentinel.office1.bg [217.75.129.210]) by hub.freebsd.org (Postfix) with SMTP id BC78237B405 for ; Fri, 26 Oct 2001 03:11:12 -0700 (PDT) Received: (qmail 53468 invoked by uid 1000); 26 Oct 2001 10:09:26 -0000 Date: Fri, 26 Oct 2001 13:09:26 +0300 From: Peter Pentchev To: arch@FreeBSD.org Subject: Re: your mail Message-ID: <20011026130926.D33751@straylight.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org References: <20011025190116.C4609@dragon.nuxi.com> <20011026024542.B12708@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011026024542.B12708@dragon.nuxi.com>; from obrien@FreeBSD.org on Fri, Oct 26, 2001 at 02:45:42AM -0700 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 On Fri, Oct 26, 2001 at 02:45:42AM -0700, David O'Brien wrote: > > Again, other than some utopian idea of a clensed spirit, what do you hope > to acomplish with this change? > > > It seems more like you just don't like the idea since > > you wouldn't use it and thus have decided to take it as a personal > > issue. It's just hardlinks to a few binaries here, not the end of the > > world. > > I will direct all the freebsd-questions email on "where did gcc" go to > you. FWIW, I'm with David here. There are lots of developers coming from non-BSD (and non-Linux) OS's, who are deeply trained to know that the system compiler might 1. perform way worse than GCC, 2. fail to grok some pretty standard C extensions and even standards, 3. need obscure options and env vars to DTRT.. All of them know that the GNU C compiler is called, well, 'gcc'. Most of them allow people to override their choice of compiler for their application, but many of them hardcode 'gcc' as the compiler name. Hordes of users know this, too. Removing the 'gcc' executable from the base system would only make those developers think that FreeBSD is somewhat wary of the GNU C compiler, and that at some point, the 'cc' bundled with FreeBSD might go the same way, so that they would once again have to build the "real" GNU C compiler separately. Even just giving an option, disabled by default, might steer people down that path of thinking. If the option is really as easy to implement as advertised, then let's have it in a searchable mailing list archive or something, so that the few people who really need it can find it and use it. For everyone else, the base C compiler is good enough, and even if it is not, there is the devel/gcc port.. Just my two cents.. G'luck, Peter -- Thit sentence is not self-referential because "thit" is not a word. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 4:18: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 324F037B401; Fri, 26 Oct 2001 04:18:03 -0700 (PDT) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id f9QBHiT92977; Fri, 26 Oct 2001 12:17:44 +0100 (BST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id f9QA2bY44136; Fri, 26 Oct 2001 11:02:37 +0100 (BST) (envelope-from mark@grondar.za) Message-Id: <200110261002.f9QA2bY44136@grimreaper.grondar.org> To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI , acpi-jp@jp.FreeBSD.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: ACPI: APM compatibility implementation References: <3BD8327C.A73CF24A@mindspring.com> In-Reply-To: <3BD8327C.A73CF24A@mindspring.com> ; from Terry Lambert "Thu, 25 Oct 2001 08:40:44 PDT." Date: Fri, 26 Oct 2001 11:02:37 +0100 From: Mark Murray 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 > 2) What kind of hardware gives a 3 hour battery life on > one battery?!? Toshiba Libretto 110CT. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 4:48:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep16-int.chello.nl (amsfep16-int.chello.nl [213.46.243.25]) by hub.freebsd.org (Postfix) with ESMTP id 53BAE37B403 for ; Fri, 26 Oct 2001 04:48:21 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep16-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011026114454.DQVD2039.amsfep16-int.chello.nl@daemon.chronias.ninth-circle.org>; Fri, 26 Oct 2001 13:44:54 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9QBej597213; Fri, 26 Oct 2001 13:40:45 +0200 (CEST) (envelope-from asmodai) Date: Fri, 26 Oct 2001 13:40:45 +0200 From: Jeroen Ruigrok/Asmodai To: Kirk McKusick Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026134045.B96876@daemon.ninth-circle.org> References: <20011025233602.587C63808@overcee.netplex.com.au> <200110260006.f9Q05vQ05273@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110260006.f9Q05vQ05273@beastie.mckusick.com> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011026 02:30], Kirk McKusick (mckusick@mckusick.com) wrote: [64-bit time_t on all platforms] >The change from 4.X to 5.0 will have enough other things going on >that I do not think that adding the time_t change would cause a >lot more pain provided that old dump tapes and log files could >be read. I can only agree with this. We have the opportunity now, lets use it. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ In the dark backward and abysm of time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 6:16:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 2BE5737B407 for ; Fri, 26 Oct 2001 06:16:18 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9QDGGb70034; Fri, 26 Oct 2001 09:16:16 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 09:16:16 -0400 (EDT) From: Garrett Wollman Message-Id: <200110261316.f9QDGGb70034@khavrinen.lcs.mit.edu> To: tlambert2@mindspring.com Cc: arch@FreeBSD.org Subject: Re: "types" man page In-Reply-To: <3BD90556.1A64F524@mindspring.com> References: <20011025190706.D41293@sunbay.com> Organization: MIT Laboratory for Computer Science Cc: 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 In article <3BD90556.1A64F524@mindspring.com> you write: >The Single UNIX Specification has a types(5) man page for the >sys/types.h header file. The Single UNIX Specification version 3 does not have an ANYTHING(5) man page. It defines interfaces, not documentation organization. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 6:42:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 58F1C37B405; Fri, 26 Oct 2001 06:42:27 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA18283; Fri, 26 Oct 2001 06:42:27 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda18281; Fri Oct 26 06:42:21 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id f9QDgJ323755; Fri, 26 Oct 2001 06:42:19 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdH23753; Fri Oct 26 06:41:54 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id f9QDfSS64291; Fri, 26 Oct 2001 06:41:28 -0700 (PDT) Message-Id: <200110261341.f9QDfSS64291@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdL64276; Fri Oct 26 06:40:50 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: bmah@FreeBSD.ORG Cc: Mike Barcroft , Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK In-reply-to: Your message of "Thu, 25 Oct 2001 22:12:15 PDT." <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Oct 2001 06:40:50 -0700 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 In message <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com>, "Bruce A . Mah" writes: > If memory serves me right, Mike Barcroft wrote: > > Bill Fenner writes: > > > >bawk is license friendly for us. > > > > > > "without fee" is license friendly for us? > > > > The way I read it, the "without fee" applies to the "permission", not > > the "any purpose." That is, they grant you permission to use it for > > any purpose and don't charge you a fee. They don't require your uses > > of it be not-for-profit. > > > > It looks like a reworded 3-clause BSD license to me. :) > > Rather than us guessing at the meaning (which I feel *is* rather > ambiguous), would it make sense for someone to request clarification > from some suitable representative of Lucent, telling them exactly what > the plans are and asking if they're compatible with the license? The > Web page has a pointer to Brian Kernighan...I'm pretty sure he'd know > the answer. :-) This is an excellent idea. I recently resolved an MIT Kerberos encryption export issue just by asking. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 6:43:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep16-int.chello.nl (amsfep16-int.chello.nl [213.46.243.25]) by hub.freebsd.org (Postfix) with ESMTP id 0527837B405 for ; Fri, 26 Oct 2001 06:43:11 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep16-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011026133948.EVSL2039.amsfep16-int.chello.nl@daemon.chronias.ninth-circle.org>; Fri, 26 Oct 2001 15:39:48 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9QDXEh98136; Fri, 26 Oct 2001 15:33:14 +0200 (CEST) (envelope-from asmodai) Date: Fri, 26 Oct 2001 15:33:13 +0200 From: Jeroen Ruigrok/Asmodai To: Lyndon Nerenberg Cc: arch@freebsd.org Subject: Re: your mail Message-ID: <20011026153313.C96876@daemon.ninth-circle.org> References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110250222.f9P2M30H071765@atg.aciworldwide.com> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011025 04:30], Lyndon Nerenberg (lyndon@atg.aciworldwide.com) wrote: >18 months ago we had a conversation on the mailing list about g77 >vs. f77 as the canonical command name for the FORTRAN compiler. >The crux of the argument was that f77 was the canonical BSD name >for the command, and that's what it has been since. There was a >related argument as to whether gcc (as a name) should die as well, >but the argument was made that too many third party packages would >break as a result. For the last year I've been running my systems >with the gcc and g++ links to the respective binaries removed, and >I haven't seen much break as a result, other than a (very) few >ports which were fixed with a quick edit of their Makefile. No thanks. I know lots of people who know GCC by gcc and expect cc to be the system's compiler, whatever it may be. >Based on this, what do you think about adding a NO_GNU_COMPLER_CMD_LINKS >macro to make.conf? If set, if would prevent the linking of cc -> >gcc and c++ -> g++, freeing up /usr/local/bin/g* for the site to >decide? (And I'm not tied to that horribly long macro name, either.) I would sooner prefer the other way around. Have gcc and g++ and have a knob to not create the gcc -> cc symlink. :) -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ Speak the sweet truth... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 8: 9:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 1EE4437B403; Fri, 26 Oct 2001 08:09:08 -0700 (PDT) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id PAA03158; Fri, 26 Oct 2001 15:34:26 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01K9YN0PWFEOVLL4XA@cim.alcatel.com.au>; Fri, 26 Oct 2001 15:34:19 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9Q5YDx61165; Fri, 26 Oct 2001 15:34:13 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Fri, 26 Oct 2001 15:34:13 +1000 From: Peter Jeremy Subject: Re: cvs commit: src/sbin/newfs newfs.8 newfs.c In-reply-to: <20011014194232.A50125@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sun, Oct 14, 2001 at 07:42:32PM -0700 To: "David O'Brien" Cc: cvs-committers@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Mail-Followup-To: David O'Brien , cvs-committers@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Message-id: <20011026153413.Z75481@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200110110851.f9B8ptf60343@freefall.freebsd.org> <20011011112527.A54224@coffee.q9media.com> <20011011154203.C44561@dragon.nuxi.com> <20011013143225.B4527@ns2.freenix.org> <20011013172706.A53976@dragon.nuxi.com> <20011014160303.A22301@ns2.freenix.org> <20011014194232.A50125@dragon.nuxi.com> 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 On Sun, Oct 14, 2001 at 07:42:32PM -0700, David O'Brien wrote: >"-c" was a no-brainer as noone has ever argued that a low "-c" was >prefered (that I've seen). I can think of one case: For small filesystems, I often reduce "-c" to ensure that there are at least 2 cylinder groups (in case one superblock gets corrupted). Where there are only 2-3 CG's, I might juggle "-c" and the slice size to make the last CG the same size as the other CGs. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 8:10:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 003E237B442 for ; Fri, 26 Oct 2001 08:10:41 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 8252014C2E; Fri, 26 Oct 2001 17:10:40 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Kirk McKusick Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> From: Dag-Erling Smorgrav Date: 26 Oct 2001 17:10:40 +0200 In-Reply-To: <200110260006.f9Q05vQ05273@beastie.mckusick.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Kirk McKusick writes: > I vote for option (3), 64-bit time_t for all 64 bit architectures. > I would go along with option (4) provided that the change-over came > with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. FWIW, I add my vote to this option. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 8:47:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns2.freenix.org (ns2.freenix.org [194.117.194.82]) by hub.freebsd.org (Postfix) with ESMTP id 446D237B406; Fri, 26 Oct 2001 08:47:24 -0700 (PDT) Received: by ns2.freenix.org (Postfix/TLS, from userid 1002) id B9193AF002; Fri, 26 Oct 2001 17:47:21 +0200 (MEST) Date: Fri, 26 Oct 2001 17:47:21 +0200 From: Ollivier Robert To: cvs-committers@FreeBSD.ORG Cc: David O'Brien , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sbin/newfs newfs.8 newfs.c Message-ID: <20011026174721.A17244@ns2.freenix.org> Mail-Followup-To: cvs-committers@FreeBSD.ORG, David O'Brien , freebsd-arch@FreeBSD.ORG References: <200110110851.f9B8ptf60343@freefall.freebsd.org> <20011011112527.A54224@coffee.q9media.com> <20011011154203.C44561@dragon.nuxi.com> <20011013143225.B4527@ns2.freenix.org> <20011013172706.A53976@dragon.nuxi.com> <20011014160303.A22301@ns2.freenix.org> <20011014194232.A50125@dragon.nuxi.com> <20011026153413.Z75481@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011026153413.Z75481@gsmx07.alcatel.com.au>; from peter.jeremy@alcatel.com.au on Fri, Oct 26, 2001 at 03:34:13PM +1000 X-Operating-System: FreeBSD 5.0-CURRENT/IPv6 Sony VAIO Z505SX 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 According to Peter Jeremy: > I can think of one case: For small filesystems, I often reduce "-c" > to ensure that there are at least 2 cylinder groups (in case one > superblock gets corrupted). Where there are only 2-3 CG's, I might Agreed, '/' is one case where you want more than one cylinder group... -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #6: Thu Aug 10 17:36:11 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:11:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 6E6E337B406 for ; Fri, 26 Oct 2001 09:11:51 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA10933; Fri, 26 Oct 2001 10:34:35 -0700 (PDT) Date: Fri, 26 Oct 2001 10:34:33 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <24137.1004080687@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 ok, so take 2 bits. that leaves you with 30 bits (1 nanosecond) resolution... or to be compatible... take it from the top 2 bits.. that leaves us with 400 years either way.. enough I'd say.. for file access times.. On Fri, 26 Oct 2001, Poul-Henning Kamp wrote: > In message , Jul > ian Elischer writes: > > >ufs has enough room to fix this.. > >there has been a field defined in the on disk inode for nanosecs > >in each of the time values... > >if we take the lowest 8 bits of that field and re-assign it to be > >the highest 8 bits of the seconds, then we have time accuracy down to > >microseconds still and we expand file times by a factor > >of 256 (which is all of recorded history plus some) > > > >we just always set those bits to 0 for the next 37 years and we don;t > >really lose time resolution and we gain compatibility with the future.. > >nothing these days has nonosecond resolution there anyhow.... > > "640K is enough for anybody" > > "There is no harm in tobacco" > > "Of course I'll respect you in the morning" > > etc > > etc > > Your proposal would leave us with quarter-microsecond resolution, > and I'm pretty sure I can beat that to pulp in the next 10 years > on a RAM disk... > > There is no harm in having to run a rev on the UFS/FFS on-disk format, > when you hav 37 years to complete it. > > -- > 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:12: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 2F55137B406 for ; Fri, 26 Oct 2001 09:11:57 -0700 (PDT) Received: from dialup-209.247.142.186.dial1.sanjose1.level3.net ([209.247.142.186] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15x9a9-0006HK-00; Fri, 26 Oct 2001 09:11:41 -0700 Message-ID: <3BD98B6A.DED6D38F@mindspring.com> Date: Fri, 26 Oct 2001 09:12:26 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <24137.1004080687@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Poul-Henning Kamp wrote: > Your proposal would leave us with quarter-microsecond resolution, > and I'm pretty sure I can beat that to pulp in the next 10 years > on a RAM disk... > > There is no harm in having to run a rev on the UFS/FFS on-disk format, > when you hav 37 years to complete it. Or 10 years, if we go Julian's way. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:21:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id B067237B401 for ; Fri, 26 Oct 2001 09:21:19 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QGKYM02914; Fri, 26 Oct 2001 18:20:34 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: tlambert2@mindspring.com Cc: Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 09:12:26 PDT." <3BD98B6A.DED6D38F@mindspring.com> Date: Fri, 26 Oct 2001 18:20:33 +0200 Message-ID: <2912.1004113233@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <3BD98B6A.DED6D38F@mindspring.com>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> Your proposal would leave us with quarter-microsecond resolution, >> and I'm pretty sure I can beat that to pulp in the next 10 years >> on a RAM disk... >> >> There is no harm in having to run a rev on the UFS/FFS on-disk format, >> when you hav 37 years to complete it. > >Or 10 years, if we go Julian's way. Julians way doesn't work: it has insufficient sub-second resolution. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:23: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 6246537B41A for ; Fri, 26 Oct 2001 09:22:58 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QGMNM02955; Fri, 26 Oct 2001 18:22:23 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 10:34:33 PDT." Date: Fri, 26 Oct 2001 18:22:23 +0200 Message-ID: <2953.1004113343@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message , Ju lian Elischer writes: >ok, so take 2 bits. >that leaves you with 30 bits (1 nanosecond) resolution... >or to be compatible... take it from the top 2 bits.. >that leaves us with 400 years either way.. enough I'd say.. >for file access times.. I happen to think that such micro-optimizations turn out to be much more trouble than they are worth. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:28:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id B61A137B408; Fri, 26 Oct 2001 09:28:03 -0700 (PDT) Received: from dialup-209.247.142.186.dial1.sanjose1.level3.net ([209.247.142.186] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15x9pz-0001ql-00; Fri, 26 Oct 2001 09:28:03 -0700 Message-ID: <3BD98F48.7563B3E3@mindspring.com> Date: Fri, 26 Oct 2001 09:28:56 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@FreeBSD.org Cc: John Baldwin , arch@FreeBSD.org, Lyndon Nerenberg Subject: Re: your mail References: <20011025190116.C4609@dragon.nuxi.com> <20011026024542.B12708@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 David O'Brien wrote: [ ... on getting rid of the "gcc" name for "cc" ... ] > Again, other than some utopian idea of a clensed spirit, what do you hope > to acomplish with this change? The ability to have a single schelling point to change to replace the compiler with, for example, the Intel compiler that Intel keeps threatening to release as Open Source in order that Intel benchmarks be better than benchmarks on any other processor. > I will direct all the freebsd-questions email on "where did gcc" go to > you. Heh. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:31:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 8818337B408 for ; Fri, 26 Oct 2001 09:31:26 -0700 (PDT) Received: from dialup-209.247.142.186.dial1.sanjose1.level3.net ([209.247.142.186] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15x9tE-0005p3-00; Fri, 26 Oct 2001 09:31:25 -0700 Message-ID: <3BD99012.117E3CCE@mindspring.com> Date: Fri, 26 Oct 2001 09:32:18 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: "types" man page References: <20011025190706.D41293@sunbay.com> <200110261316.f9QDGGb70034@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Garrett Wollman wrote: > > In article <3BD90556.1A64F524@mindspring.com> you write: > > >The Single UNIX Specification has a types(5) man page for the > >sys/types.h header file. > > The Single UNIX Specification version 3 does not have an ANYTHING(5) > man page. It defines interfaces, not documentation organization. Do I need to post the entire index to section 5 off my CDROM? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:31:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 6AA6737B403 for ; Fri, 26 Oct 2001 09:31:48 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA11014; Fri, 26 Oct 2001 10:49:43 -0700 (PDT) Date: Fri, 26 Oct 2001 10:49:41 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <3BD98B6A.DED6D38F@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 considering that we didn't have ANY sub-second resolution for a long time I think that looking for sub microsecond resolution on access times is pointless at this time.. In any case, if you just take the top 2 bits you still have nanosec resolution, and 400 years either way. that at least should give us time to migrate to other filesystems and get all active machines retired.. (which is actually the issue, assuming that at some time in the future all new systems will be created with UFS2). On Fri, 26 Oct 2001, Terry Lambert wrote: > Poul-Henning Kamp wrote: > > Your proposal would leave us with quarter-microsecond resolution, > > and I'm pretty sure I can beat that to pulp in the next 10 years > > on a RAM disk... > > > > There is no harm in having to run a rev on the UFS/FFS on-disk format, > > when you hav 37 years to complete it. > > Or 10 years, if we go Julian's way. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:32:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by hub.freebsd.org (Postfix) with ESMTP id 2E3F337B408; Fri, 26 Oct 2001 09:32:27 -0700 (PDT) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.11.6/8.11.5) with ESMTP id f9QGTwa79290; Fri, 26 Oct 2001 12:30:00 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Message-Id: <200110261630.f9QGTwa79290@aldan.algebra.com> Date: Fri, 26 Oct 2001 12:29:55 -0400 (EDT) From: Mikhail Teterin Subject: Re: cvs commit: src/sbin/newfs newfs.8 newfs.c To: peter.jeremy@alcatel.com.au Cc: obrien@FreeBSD.org, cvs-committers@FreeBSD.org, freebsd-arch@FreeBSD.org In-Reply-To: <20011026153413.Z75481@gsmx07.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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 On 26 Oct, Peter Jeremy wrote: > On Sun, Oct 14, 2001 at 07:42:32PM -0700, David O'Brien wrote: >>"-c" was a no-brainer as noone has ever argued that a low "-c" was >>prefered (that I've seen). > > I can think of one case: For small filesystems, I often reduce "-c" to > ensure that there are at least 2 cylinder groups (in case one > superblock gets corrupted). Where there are only 2-3 CG's, I might > juggle "-c" and the slice size to make the last CG the same size as > the other CGs. Why don't we make newfs apply this (and/or similar) heuristics by default -- when no options are specified? -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:39:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8A99837B401 for ; Fri, 26 Oct 2001 09:39:31 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QGcsM03465; Fri, 26 Oct 2001 18:38:54 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Terry Lambert , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 10:49:41 PDT." Date: Fri, 26 Oct 2001 18:38:54 +0200 Message-ID: <3463.1004114334@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message , Ju lian Elischer writes: >considering that we didn't have ANY sub-second resolution for a long time >I think that >looking for sub microsecond resolution on access times is pointless at >this time.. I am looking for it at this time, not _for_ this time, but _for_ the future. If state of the art equipment can break the make(1) assumption today, what do you think the life expectancy of the designed concept is ? Certainly not 10+ years. And have you considered that there may be other and stronger requirements than make(1) and that multi-cpu, multi-threaded systems may push the envelope ? Solving the problem means going for a timestamp which can resolve any conceiveable CPU frequencies for all relevant future. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:42:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 9C20037B405 for ; Fri, 26 Oct 2001 09:42:49 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 84E4C81D0A; Fri, 26 Oct 2001 11:42:49 -0500 (CDT) Date: Fri, 26 Oct 2001 11:42:49 -0500 From: Alfred Perlstein To: Poul-Henning Kamp Cc: Julian Elischer , Terry Lambert , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026114249.E15052@elvis.mu.org> References: <3463.1004114334@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3463.1004114334@critter.freebsd.dk>; from phk@critter.freebsd.dk on Fri, Oct 26, 2001 at 06:38:54PM +0200 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 * Poul-Henning Kamp [011026 11:39] wrote: > In message , Ju > lian Elischer writes: > > >considering that we didn't have ANY sub-second resolution for a long time > >I think that > >looking for sub microsecond resolution on access times is pointless at > >this time.. > > I am looking for it at this time, not _for_ this time, but _for_ > the future. > > If state of the art equipment can break the make(1) assumption today, > what do you think the life expectancy of the designed concept is ? > > Certainly not 10+ years. > > And have you considered that there may be other and stronger > requirements than make(1) and that multi-cpu, multi-threaded systems > may push the envelope ? > > Solving the problem means going for a timestamp which can resolve > any conceiveable CPU frequencies for all relevant future. I guess I should have more in depth knowledge of these systems by now, but what's wrong with having the in-core being a full 64/128/whatever bits while the on disk itself doesn't? At least until Kirk does his new layout, it might be a compromise to regain out 2037 safety a bit early on. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:45:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id D5B4437B408 for ; Fri, 26 Oct 2001 09:45:46 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QGj8M03688; Fri, 26 Oct 2001 18:45:08 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: Julian Elischer , Terry Lambert , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 11:42:49 CDT." <20011026114249.E15052@elvis.mu.org> Date: Fri, 26 Oct 2001 18:45:08 +0200 Message-ID: <3686.1004114708@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <20011026114249.E15052@elvis.mu.org>, Alfred Perlstein writes: >> And have you considered that there may be other and stronger >> requirements than make(1) and that multi-cpu, multi-threaded systems >> may push the envelope ? >> >> Solving the problem means going for a timestamp which can resolve >> any conceiveable CPU frequencies for all relevant future. > >I guess I should have more in depth knowledge of these systems by >now, but what's wrong with having the in-core being a full >64/128/whatever bits while the on disk itself doesn't? Because applications in core write files on disk ? :-) I'm merely advocating solving the problem and not hacking around it. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:46:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 8E4E437B407 for ; Fri, 26 Oct 2001 09:46:51 -0700 (PDT) Received: from dialup-209.247.142.186.dial1.sanjose1.level3.net ([209.247.142.186] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15xA81-0006qT-00; Fri, 26 Oct 2001 09:46:42 -0700 Message-ID: <3BD993A6.E6B12512@mindspring.com> Date: Fri, 26 Oct 2001 09:47:34 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <2912.1004113233@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Poul-Henning Kamp wrote: > >> There is no harm in having to run a rev on the UFS/FFS on-disk format, > >> when you hav 37 years to complete it. > > > >Or 10 years, if we go Julian's way. > > Julians way doesn't work: it has insufficient sub-second resolution. According to you, that won't bite anyone for 10 years. Also: no one has ever justified this for anything other than "make", which looks only at mtime, so having such high resolution for atime and ctime is really not necessary, unless it can be justified. I have yet to see a demonstration of another system failing and FreeBSD succeeding as a result of the time resolution on file timestamps. The "mtime" argument is really only valid in the case that you rerun a build in a subsecond time with generated source code, such that the generate code ends up with the same mtime timestamp as the previously generated object code. I fully admit that subsecond resolution on mtime is necessary to avoid stale files in the case that you can regenerate them with different contents in under a second since the previous build. Frankly, I'd be much more concerned that the local time is not sent with all NFSv4 requests, so that the local delta can be calculated, rather than relying on unreliable ntpd drift synchronization, which is certainly in the second range in unreliability. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:51:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id F3FD937B403 for ; Fri, 26 Oct 2001 09:51:34 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA11147; Fri, 26 Oct 2001 11:00:54 -0700 (PDT) Date: Fri, 26 Oct 2001 11:00:53 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp Cc: tlambert2@mindspring.com, Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <2912.1004113233@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 I thonk you are wrong.. here's the way I see it.. Kirk is working on UFS2. All new systemsafter about the next 5 or 6 years will be created with UFS2. Therefore what we are looking for is a way that exisiting embedded systems can continue to run safely past 2038. (actually file access times ON DISK should be treated as unsigned as there were no UFS systems before 1970 but I digress) There are not going to be UP systems in the next 6 years tha can touch 2 DIFFERNT files withinn the same microsecond, and even if a MP system did so, there is no reason to not give them the same Microsecond timestamp, since they could have been to the same nanosecond too. At least we know that they do not have interdependencies or the system wouldn;t have scheduled them to differnt processors where the relative completion times couldn't be controlled. so it doesn't matter that we only have uSec resolution in that field.. but here;s a better idea anyhow.. take the TOP 2 bits.. they can never be used now anyhow.... that gives us nanosecond resolution, which is all we can report now anyway, and multiplies the seconds range by 4. Assuming that we do not allow access times < 1970 on disk (there were no such files then, then we are ok up to the year 2600, by which time we hope there are no embededded systems from the next 5 years still running..... On Fri, 26 Oct 2001, Poul-Henning Kamp wrote: > In message <3BD98B6A.DED6D38F@mindspring.com>, Terry Lambert writes: > >Poul-Henning Kamp wrote: > >> Your proposal would leave us with quarter-microsecond resolution, > >> and I'm pretty sure I can beat that to pulp in the next 10 years > >> on a RAM disk... > >> > >> There is no harm in having to run a rev on the UFS/FFS on-disk format, > >> when you hav 37 years to complete it. > > > >Or 10 years, if we go Julian's way. > > Julians way doesn't work: it has insufficient sub-second resolution. > > -- > 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 9:52:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 8C0A537B407 for ; Fri, 26 Oct 2001 09:52:44 -0700 (PDT) Received: from dialup-209.247.142.186.dial1.sanjose1.level3.net ([209.247.142.186] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15xADo-0005XR-00; Fri, 26 Oct 2001 09:52:41 -0700 Message-ID: <3BD9950D.BB72A8F9@mindspring.com> Date: Fri, 26 Oct 2001 09:53:33 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <3463.1004114334@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Poul-Henning Kamp wrote: > I am looking for it at this time, not _for_ this time, but _for_ > the future. > > If state of the art equipment can break the make(1) assumption today, > what do you think the life expectancy of the designed concept is ? > > Certainly not 10+ years. > > And have you considered that there may be other and stronger > requirements than make(1) and that multi-cpu, multi-threaded systems > may push the envelope ? > > Solving the problem means going for a timestamp which can resolve > any conceiveable CPU frequencies for all relevant future. You can alternately resolve this problem by forcing the timestamp to be monotonically increasing, FWIW. This means that you might push the timestamp into the future by several *gasp* nanoseconds, but it would guarantee that a very fast system would maintain dependency order correctly for generated files for make. This could be done in the FS, without any ugly hacks... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10: 4:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 93F7937B408 for ; Fri, 26 Oct 2001 10:04:12 -0700 (PDT) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id f9QH0d458451; Fri, 26 Oct 2001 10:00:39 -0700 (PDT) (envelope-from dg) Date: Fri, 26 Oct 2001 10:00:39 -0700 From: David Greenman To: Julian Elischer Cc: Poul-Henning Kamp , tlambert2@mindspring.com, Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026100039.C58218@nexus.root.com> References: <2912.1004113233@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from julian@elischer.org on Fri, Oct 26, 2001 at 11:00:53AM -0700 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 >but here;s a better idea anyhow.. > >take the TOP 2 bits.. they can never be used now anyhow.... >that gives us nanosecond resolution, which is all we can report now >anyway, and multiplies the seconds range by 4. Assuming that we do not >allow access times < 1970 on disk (there were no such files then, >then we are ok up to the year 2600, by which time we hope there are no >embededded systems from the next 5 years still running..... Any solution that tries to bandaid the problem by using a few bits from here or there is unacceptable to me. I have mixed feelings about changing to phk's 1/1^64 fractional timestamp idea, but I do think that we should make time_t 64 bits on all architectures, including x86, starting with v5 of FreeBSD. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10: 6:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 4A11237B403 for ; Fri, 26 Oct 2001 10:06:32 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9QH6PJ88998 for ; Fri, 26 Oct 2001 13:06:25 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011025184936.A4609@dragon.nuxi.com> References: <20011025233602.587C63808@overcee.netplex.com.au> <20011025184936.A4609@dragon.nuxi.com> Date: Fri, 26 Oct 2001 13:06:23 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 6:49 PM -0700 10/25/01, David O'Brien wrote: >Thus I want time_t to be the same size on every FreeBSD platform so >that time wrap-arounds happen in the same way on the most popular >platform (read i386) which gets a lot of testing and defines what >is FreeBSD in behavior, and the Alpha platform (which at times seems >to only have a hand-full of users). As we get more platforms, we >are only going to have more of the problem of FreeBSD really only >being well used on one of our offered architectures. Actually, I expect the opposite to happen. I can get my hands on both PowerPC and Sparc64 machines a lot easier than Alpha machines, and certainly Intel is going to push to make IA-64 very common. As these new "higher-volume" platforms come online, I expect a larger percentage of FreeBSD users will be using machines that are NOT i386... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10: 7:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C1DA437B403 for ; Fri, 26 Oct 2001 10:07:50 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QH7F437553; Fri, 26 Oct 2001 10:07:15 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 10:07:15 -0700 (PDT) From: Matthew Dillon Message-Id: <200110261707.f9QH7F437553@apollo.backplane.com> To: Julian Elischer Cc: Terry Lambert , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: 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 For UFS we obviously re-coopt the nanosecond field. Thanks Kirk! I suggest simply changing di_atimensec (and friends) to di_atimemsb, to hold the msb 32 bits, allowing us to maintain backwards compatibility. The question before us is whether we should eat some of those 64 bits and attempt to store sub-second timestamps. This is a bad idea. There's no point, because processors are only getting faster. Even nanosecond resolution isn't enough and we have other issues simply due to new computing methodologies such as parallel and distributed processing. 'make's issues aren't enough to justify complexifying atime/ctime/mtime. The larger problem that we need to solve are the ridiculous calendar limitations. We have to solve the problem *permanently* this time, we have to solve them obviously, with as little additional complexity as possible. We have to have a solution that is *uniform* across the system, and a full 64 bit 1-second resolution field will do that. We should not be screwing around with other clutter. I am not against adding additional fields to struct stat to support sub-second resolution for mtime, but I am against attempting to integrate such fields into st_atime/st_mtime/st_ctime directly. Unfortunately we only have two spare 64 bit fields in struct nstat. They aren't enough to fix the time fields and maintain backwards compatibility. Unless I'm missing something here, we are going to have to roll new syscalls for *stat() and *utimes() (any others?) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10: 8:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 294D237B405; Fri, 26 Oct 2001 10:08:29 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9QHCAx00903; Fri, 26 Oct 2001 13:12:10 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Oct 2001 13:12:10 -0400 From: Mike Barcroft To: "Bruce A. Mah" Cc: Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011026131209.B355@coffee.q9media.com> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com>; from bmah@FreeBSD.ORG on Thu, Oct 25, 2001 at 10:12:15PM -0700 Organization: The FreeBSD Project 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 Bruce A. Mah writes: > Rather than us guessing at the meaning (which I feel *is* rather > ambiguous), would it make sense for someone to request clarification > from some suitable representative of Lucent, telling them exactly what > the plans are and asking if they're compatible with the license? The > Web page has a pointer to Brian Kernighan...I'm pretty sure he'd know > the answer. :-) Bruce, Since you came up with the idea, do you want to contact Lucent and report back to the list when you find an answer? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10:10:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 2566E37B403 for ; Fri, 26 Oct 2001 10:10:17 -0700 (PDT) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f9QHAEH10055; Fri, 26 Oct 2001 10:10:14 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Fri, 26 Oct 2001 10:10:15 -0700 (PDT) From: Matthew Jacob Reply-To: To: Garance A Drosihn Cc: Subject: Re: 64 bit times revisited.. In-Reply-To: Message-ID: <20011026100750.H68844-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 > At 6:49 PM -0700 10/25/01, David O'Brien wrote: > >Thus I want time_t to be the same size on every FreeBSD platform so > >that time wrap-arounds happen in the same way on the most popular > >platform (read i386) which gets a lot of testing and defines what > >is FreeBSD in behavior, and the Alpha platform (which at times seems > >to only have a hand-full of users). As we get more platforms, we > >are only going to have more of the problem of FreeBSD really only > >being well used on one of our offered architectures. > > Actually, I expect the opposite to happen. I can get my hands > on both PowerPC and Sparc64 machines a lot easier than Alpha > machines, and certainly Intel is going to push to make IA-64 > very common. As these new "higher-volume" platforms come online, > I expect a larger percentage of FreeBSD users will be using > machines that are NOT i386... > I would expect Intel to in fact *not* push IA-64 for desktop machines- at least not for several years. They would osborne themselves out of their main revenue stream *and* open themselves up to a horde of mini-AMDs coming in and snagging that market. *Unless* Micros$ft makes a new release of XP 64 bit. And we all know how enthusiasitc they were about the Alpha 64 bit port for NT...... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10:30:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id C28AD37B406 for ; Fri, 26 Oct 2001 10:30:06 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9QHTuJ56180; Fri, 26 Oct 2001 13:29:59 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200110260047.f9Q0lsf16513@apollo.backplane.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> Date: Fri, 26 Oct 2001 13:29:53 -0400 To: Matthew Dillon , Poul-Henning Kamp From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Cc: Peter Wemm , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 5:47 PM -0700 10/25/01, Matthew Dillon wrote: >:I vote for option (3), 64-bit time_t for all 64 bit architectures. >:I would go along with option (4) provided that the change-over came >:with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > > I agree completely. 64 bit time_t for all 64 bit archs, and > frankly I would also like to see a 64 bit time_t for 5.x on 32 > bit archs... lets get the pain over and done with now rather > then later. Let me waste a few electrons by also agreeing to this general direction. We are hoping to bring on new platforms of sparc64 and ia-64 for the 5.0-timeframe (or certainly before the 6.0 timeframe). It would be exceedingly stupid to start out those 64-bit platforms on 32-bit time_t's, when we KNOW we will have switch to 64-bit times at some later point. So, I would put in a very strong, pound-the-table vote for 64-bit time_t on 64-bit architectures. Given 64-bit time_t's for the new platforms, we might as well go for 64-bit times on all platforms (although we obviously can not MFC that back into the 4.x-branch for 32-bit platforms). I don't feel quite so strongly about 64-bit time_t's on 32-bit architectures, but it does seem like the right thing to do. I don't have any strong feelings on the specifics of how we get to 64-bit time_t's. I do think the following suggestion seems like a worthwhile idea, but maybe I am unaware of some reason that it would be a problem. At 8:28 AM +0200, Poul-Henning Kamp wrote: >I would like for us to introduce a new format of timestamps: > > struct time$something { > time_t tx_sec; /* 64bit */ > uint_64_t tx_fsec; /* binary fraction of second */; > } > >If we have access to a int_128_t type, we could instead simply >define a scalar type 128 bits wide, resolved in 1/(1<<64) seconds >(.0542E-18 == .0542 attoseconds) > >This format would be faster for any kind of arithmetic, including >inside the timecounter code, and it would have sufficient bits in >both directions for any forseeable future. So, I'll also add a vote towards that idea, although it might be easy to convince me that some other idea would much better. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10:35:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 269E737B405 for ; Fri, 26 Oct 2001 10:35:27 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 0081481D09; Fri, 26 Oct 2001 12:35:26 -0500 (CDT) Date: Fri, 26 Oct 2001 12:35:26 -0500 From: Alfred Perlstein To: Poul-Henning Kamp Cc: Julian Elischer , Terry Lambert , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026123526.F15052@elvis.mu.org> References: <20011026114249.E15052@elvis.mu.org> <3686.1004114708@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3686.1004114708@critter.freebsd.dk>; from phk@critter.freebsd.dk on Fri, Oct 26, 2001 at 06:45:08PM +0200 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 * Poul-Henning Kamp [011026 11:45] wrote: > In message <20011026114249.E15052@elvis.mu.org>, Alfred Perlstein writes: > > >> And have you considered that there may be other and stronger > >> requirements than make(1) and that multi-cpu, multi-threaded systems > >> may push the envelope ? > >> > >> Solving the problem means going for a timestamp which can resolve > >> any conceiveable CPU frequencies for all relevant future. > > > >I guess I should have more in depth knowledge of these systems by > >now, but what's wrong with having the in-core being a full > >64/128/whatever bits while the on disk itself doesn't? > > Because applications in core write files on disk ? :-) Excuse me for being daft, but isn't some of the resolution currently in the on-disk portion more than the time it takes to write and re-read the data from most media? Are you concerned with faster media? Perhaps MFS? > I'm merely advocating solving the problem and not hacking around it. I think that means we wait for Kirk's new layout. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10:39:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from c527597-a.cstvl1.sfba.home.com (c527597-a.cstvl1.sfba.home.com [24.176.204.87]) by hub.freebsd.org (Postfix) with ESMTP id AE1EB37B405; Fri, 26 Oct 2001 10:39:55 -0700 (PDT) Received: (from bmah@localhost) by c527597-a.cstvl1.sfba.home.com (8.11.6/8.11.6) id f9QHdth48596; Fri, 26 Oct 2001 10:39:55 -0700 (PDT) (envelope-from bmah) Message-Id: <200110261739.f9QHdth48596@c527597-a.cstvl1.sfba.home.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mike Barcroft Cc: "Bruce A. Mah" , Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK In-Reply-To: <20011026131209.B355@coffee.q9media.com> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> <20011026131209.B355@coffee.q9media.com> Comments: In-reply-to Mike Barcroft message dated "Fri, 26 Oct 2001 13:12:10 -0400." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-519609874P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 26 Oct 2001 10:39:55 -0700 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 --==_Exmh_-519609874P Content-Type: text/plain; charset=us-ascii If memory serves me right, Mike Barcroft wrote: > Bruce A. Mah writes: [we should ask Lucent about bawk licensing] > Since you came up with the idea, do you want to contact Lucent and > report back to the list when you find an answer? OK. Bruce. --==_Exmh_-519609874P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE72Z/q2MoxcVugUsMRAiLqAJ9nBjcux/nberZy3mayXCvYZif9xgCeMOCV a2Sr2s5jykBiC7pfPCbD8Fg= =I0Dd -----END PGP SIGNATURE----- --==_Exmh_-519609874P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10:48:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rodney.cnchost.com (rodney.concentric.net [207.155.252.4]) by hub.freebsd.org (Postfix) with ESMTP id B160D37B403 for ; Fri, 26 Oct 2001 10:48:16 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by rodney.cnchost.com id NAA22627; Fri, 26 Oct 2001 13:48:10 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110261748.NAA22627@rodney.cnchost.com> To: Poul-Henning Kamp Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Fri, 26 Oct 2001 08:28:14 +0200." <23015.1004077694@critter.freebsd.dk> Date: Fri, 26 Oct 2001 10:48:10 -0700 From: Bakul Shah 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 > We are now routinely talking about GHz+ CPUs, but struct timespec > can only do nanosecond resolution and arithmetic on timeval and > timespec sux badly. > I would like for us to introduce a new format of timestamps: > struct time$something { > time_t tx_sec; /* 64bit */ > uint_64_t tx_fsec; /* binary fraction of second */; > } > > If we have access to a int_128_t type, we could instead simply > define a scalar type 128 bits wide, resolved in 1/(1<<64) seconds > (.0542E-18 == .0542 attoseconds) > > This format would be faster for any kind of arithmetic, including > inside the timecounter code, and it would have sufficient bits in > both directions for any forseeable future. A 64 bit time_t with nanosecond resolution would last you, let us see... 2^64/10^9/86400/365.25 or 584 years. Do we really need timespec or 128 bit time values? Yes, this is short sighted but 500+ years is a long enough time to develop 128 bit time. So I say abolish clunky structs like timespec and timeval in favor of a 64 bit time type (or 128 bit, if you can convince people). IMHO there is not much point in using file timestamps of resolutions less than 1 ns -- that is about 1 foot of travel at the speed of light. Note that even a ns resolution will cause problems on a multi-processor system where cpu nodes are more than a foot or so apart -- a parallel make may allocate jobs to processor nodes in such a way that a file created later will have an earlier timestamp. Even if you synchronize them your processor interconnect has to provide predictable times to deliver data from node A to node B -- this is not usually the case. So I believe you need < ns resolution only when a *single* node can update files faster than a ns. For specialized applications such as test equipment one may need finer resolution but usually such embedded applications don't run for 500 years continuously. Perhaps the 64 bit time_t should be named longtime_t -- actually that is a serious suggestion! There is no need to retire the 32 bit time_t -- we will have to deal with old dump tapes and saved file systems for a long time so we will need it in some form. So, just like ascii (char) and unicode (wchar_t), why define a _new_ time type and insist people start using that for new software? Then the current time_t is valid only in the first "epoch". Okay, how about this? Define N types that will be *exactly* the same on *all* machines: time_t 32 bits (1 second resolution, upto yr 2038) nstime64_t 64 bits (10^-9 second resolution, upto yr 2554) zstime128_t 128 bits (10^-21 second resolution, 10 billion yrs) zs prefix because 10^-21 == zopto. On-storage structures should use one of the three above types. Perhaps the superblock or header should contain a zstime128_t value indicating the base epoch (a point in time). Add more types if you wish but please, abolish the clunky timespec and timeval altogether! BTW, this discussion should be conducted on comp.std.internat as it affects all OSes, not just FreeBSD. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 10:50:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by hub.freebsd.org (Postfix) with ESMTP id 4AC4B37B403 for ; Fri, 26 Oct 2001 10:50:18 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by marlborough.cnchost.com id NAA29175; Fri, 26 Oct 2001 13:50:10 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110261750.NAA29175@marlborough.cnchost.com> To: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Fri, 26 Oct 2001 10:48:10 PDT." <200110261748.NAA22627@rodney.cnchost.com> Date: Fri, 26 Oct 2001 10:50:10 -0700 From: Bakul Shah 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 I wrote: > need it in some form. So, just like ascii (char) and unicode > (wchar_t), why define a _new_ time type and insist people > start using that for new software? Then the current time_t > is valid only in the first "epoch". The second line should be: (wchar_t), why not define a _new_ time type and insist people Sorry! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11: 0:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from agamemnon.cnchost.com (agamemnon.cnchost.com [207.155.252.31]) by hub.freebsd.org (Postfix) with ESMTP id E037837B405 for ; Fri, 26 Oct 2001 11:00:17 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by agamemnon.cnchost.com id NAA14223; Fri, 26 Oct 2001 13:59:53 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110261759.NAA14223@agamemnon.cnchost.com> To: Alfred Perlstein Cc: Poul-Henning Kamp , Julian Elischer , Terry Lambert , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Fri, 26 Oct 2001 12:35:26 CDT." <20011026123526.F15052@elvis.mu.org> Date: Fri, 26 Oct 2001 10:59:53 -0700 From: Bakul Shah 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 > Excuse me for being daft, but isn't some of the resolution currently > in the on-disk portion more than the time it takes to write and > re-read the data from most media? Are you concerned with faster > media? Perhaps MFS? Depends on *when* a file is timestamped. If the timestamp is done after the write has been pushed to the disk and confirmed as having written then you are right. If it is timestamped when a file operation has been completed and write queued to the disk driver, it is conceivable timestamps may be just a few hundreds of ns apart on even today's machines. If files are written by two different machines to two different filesystems (but they are related in make's eyes) their timestamps may be arbitrarily close but as I indicated in my previous email distributed systems bring their own set of problems which get exacerbated as you use finer time resolution. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11: 1:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id A30A437B405 for ; Fri, 26 Oct 2001 11:01:51 -0700 (PDT) Received: (qmail 2094 invoked by uid 1000); 26 Oct 2001 18:02:13 -0000 Date: Fri, 26 Oct 2001 11:01:51 -0701 From: Jos Backus To: arch@freebsd.org Subject: Re: 64 bit times revisited.. Message-ID: <20011026110151.A1584@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: arch@freebsd.org References: <20011026100750.H68844-100000@wonky.feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026100750.H68844-100000@wonky.feral.com> User-Agent: Mutt/1.3.23i 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 On Fri, Oct 26, 2001 at 10:10:15AM -0700, Matthew Jacob wrote: > *Unless* Micros$ft makes a new release of XP 64 bit. And we all know how > enthusiasitc they were about the Alpha 64 bit port for NT...... http://www.microsoft.com/windowsxp/64bit/techinfo/planning/techoverview/default.asp http://www.microsoft.com/windowsxp/64bit/howtobuy.asp -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11: 7:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 41A4637B403 for ; Fri, 26 Oct 2001 11:07:13 -0700 (PDT) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f9QI75H10586; Fri, 26 Oct 2001 11:07:05 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Fri, 26 Oct 2001 11:07:05 -0700 (PDT) From: Matthew Jacob Reply-To: To: Jos Backus Cc: Subject: Re: 64 bit times revisited.. In-Reply-To: <20011026110151.A1584@lizzy.bugworks.com> Message-ID: <20011026110702.A68844-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 *gag* On Fri, 26 Oct 2001, Jos Backus wrote: > On Fri, Oct 26, 2001 at 10:10:15AM -0700, Matthew Jacob wrote: > > *Unless* Micros$ft makes a new release of XP 64 bit. And we all know how > > enthusiasitc they were about the Alpha 64 bit port for NT...... > > http://www.microsoft.com/windowsxp/64bit/techinfo/planning/techoverview/default.asp > http://www.microsoft.com/windowsxp/64bit/howtobuy.asp > > -- > Jos Backus _/ _/_/_/ Santa Clara, CA > _/ _/ _/ > _/ _/_/_/ > _/ _/ _/ _/ > josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11:22:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 118A937B401 for ; Fri, 26 Oct 2001 11:22:14 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QILTM05203; Fri, 26 Oct 2001 20:21:29 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: Julian Elischer , Terry Lambert , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 12:35:26 CDT." <20011026123526.F15052@elvis.mu.org> Date: Fri, 26 Oct 2001 20:21:29 +0200 Message-ID: <5201.1004120489@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <20011026123526.F15052@elvis.mu.org>, Alfred Perlstein writes: >> Because applications in core write files on disk ? :-) > >Excuse me for being daft, but isn't some of the resolution currently >in the on-disk portion more than the time it takes to write and >re-read the data from most media? Are you concerned with faster >media? Perhaps MFS? Not all filesystems are backed by disk, some (like DEVFS) have no physical backing at all. Second, with softupdates, even physically backed disks are not constrained to a physical movement for each transaction. Third, I want people to consider for a moment what the world looked like 10 years ago. Now who here dare predict if we will need or not need nanosecond (or better) resolution for timestamps 10 years down the road ? After all, PC cpu clock frequencies have only increased by a factor 42[*] or so in the last 10 years... Ten years down the road, people might curse us for wasting two bits which could have split the nanoseconds to solve a problem which is by then still 27 years down the road... So what I'm advocating is to discuss this with Kirk for his FFS2 layout, and realize that very few of the media which holds todays filesystems will still be rotating 10 years from now. I do, by the way, find it much more interesting to discuss if future inodes should contain counters counting number of R/O opens, number of R/W opens, number of sectors written etc etc. Such statistics could be used to optimize layout based on actual statistics, rather than statistical guesswork as we do now... Poul-Henning [*] 1400MHz / 33 MHz = 42.4242424242, there is probably no cosmic significance in this numer. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11:31:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id F041E37B401 for ; Fri, 26 Oct 2001 11:31:50 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA11702; Fri, 26 Oct 2001 12:50:01 -0700 (PDT) Date: Fri, 26 Oct 2001 12:49:59 -0700 (PDT) From: Julian Elischer To: David Greenman Cc: Poul-Henning Kamp , tlambert2@mindspring.com, Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011026100039.C58218@nexus.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 26 Oct 2001, David Greenman wrote: > >but here;s a better idea anyhow.. > > > >take the TOP 2 bits.. they can never be used now anyhow.... > >that gives us nanosecond resolution, which is all we can report now > >anyway, and multiplies the seconds range by 4. Assuming that we do not > >allow access times < 1970 on disk (there were no such files then, > >then we are ok up to the year 2600, by which time we hope there are no > >embededded systems from the next 5 years still running..... This is just to keep systems that are built using UFS in an embedded (probably solid-state disk based) system CAPABLE of running past 2038. The SIMPLEST answer is to declare the seconds to be UNSIGNED. that extends us for another 70 odd years. > > Any solution that tries to bandaid the problem by using a few bits from > here or there is unacceptable to me. I have mixed feelings about changing > to phk's 1/1^64 fractional timestamp idea, but I do think that we should > make time_t 64 bits on all architectures, including x86, starting with v5 > of FreeBSD. that would be 1/2^64 no? (actually a nice idea but not very standard..) > > -DG > > David Greenman > Co-founder, The FreeBSD Project - http://www.freebsd.org > President, TeraSolutions, Inc. - http://www.terasolutions.com > Pave the road of life with opportunities. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11:36:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8A1B437B401 for ; Fri, 26 Oct 2001 11:36:03 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QIYwM05687; Fri, 26 Oct 2001 20:34:59 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bakul Shah Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 10:48:10 PDT." <200110261748.NAA22627@rodney.cnchost.com> Date: Fri, 26 Oct 2001 20:34:58 +0200 Message-ID: <5685.1004121298@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110261748.NAA22627@rodney.cnchost.com>, Bakul Shah writes: >Okay, how about this? Define N types that will be >*exactly* the same on *all* machines: > > time_t 32 bits (1 second resolution, upto yr 2038) > nstime64_t 64 bits (10^-9 second resolution, upto yr 2554) Should be 1/2^32 resolution or you have a math nightmare dividing by 1000000000 all the time. > zstime128_t 128 bits (10^-21 second resolution, 10 billion yrs) here: resolution 1/2^64 second. Decimal computers lost the race and they ain't coming back. We want arithmetic on binary computers to be fast and simple. The three types such ammended, can be trivially truncated and zero-extended to each other, which will undoubtedly be a good thing. >Add more types if you wish but please, abolish the >clunky timespec and timeval altogether! Well, we'll have to maintain them for traditional (timeval) and brain-damaged extension (timespec) syscalls, but otherwise: YES!!! >BTW, this discussion should be conducted on comp.std.internat >as it affects all OSes, not just FreeBSD. Well, sorry, ENOTIME from here. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11:57:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5042E37B407 for ; Fri, 26 Oct 2001 11:57:48 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9QIvjJ64914; Fri, 26 Oct 2001 14:57:45 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3BD993A6.E6B12512@mindspring.com> References: <2912.1004113233@critter.freebsd.dk> <3BD993A6.E6B12512@mindspring.com> Date: Fri, 26 Oct 2001 14:57:42 -0400 To: tlambert2@mindspring.com, Poul-Henning Kamp From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 >Also: no one has ever justified this for anything other >than "make", which looks only at mtime, so having such >high resolution for atime and ctime is really not necessary, >unless it can be justified. >The "mtime" argument is really only valid in the case that >you rerun a build in a subsecond time with generated source >code, such that the generate code ends up with the same >mtime timestamp as the previously generated object code. I >fully admit that subsecond resolution on mtime is necessary >to avoid stale files in the case that you can regenerate >them with different contents in under a second since the >previous build. As an aside, let me make an observation about 'make'. It is just an observation about 'make' and timestamps though. I do completely support the idea of having higher-resolution timestamps for many purposes, including 'mtime'. However, when the specific example of 'make' comes up, I think people are naive to think that even infinite-resolution timestamps will fully address the issue of make. When 'make' is processing it: a) checks timestamps of source files vs target b) noticed target is out-of-date. c) executes commands to create the new target d) at the end of all those commands, a new timestamp is set on the target file. Step c can be many commands, and can easily require millions or billions of instructions. It can not be done in zero time. If any *other* process changes any of the source files at the same time that 'make' is doing steps b&c, then the target should be remade, but the timestamp set in step d will be "after" the change made to the source file. So, we should have higher-resolution timestamps, but they will not really solve all the problems of 'make'... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 11:59:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BB7B537B401; Fri, 26 Oct 2001 11:59:22 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id EAA06213; Sat, 27 Oct 2001 04:59:15 +1000 Date: Sat, 27 Oct 2001 04:58:18 +1000 (EST) From: Bruce Evans X-X-Sender: To: Dag-Erling Smorgrav Cc: Ruslan Ermilov , Subject: Re: "types" man page In-Reply-To: Message-ID: <20011027044359.H88870-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On 25 Oct 2001, Dag-Erling Smorgrav wrote: > Ruslan Ermilov writes: > > On Wed, Oct 24, 2001 at 07:52:26PM +0200, Dag-Erling Smorgrav wrote: > > > Ruslan, do you have a suggestion for the proper mdoc incantations for > > > a types(7) entry, based on the items I listed in my original mail? > > Just give me an example entry, and I will mark it up as needed. > > pid_t > Used to store a process ID. > Defined in . This is a (wrong) implementation detail. pid_t is defined in (POSIX.1-1990 standard; perhaps in other places in POSIX.1-200x). only defines _BSD_PID_T. This should probably not be documented here. > Equivalent to a signed int on all platforms. Another implementation detail. The standard specification shuld be given at least as much weight as the implementation details here. > The man page should also have a section that describes the > relationships between the various headers (including but probably not > limited to , , , > and ) that either define these types or is essentially irrelevant for types. > include other headers which define them. For instance, most programs > will want to include or to define pid_t, > though or would do. Neither nor would do. would only do because of (documented) namespace pollution. Types are parameters. There could be another man page giving relationships between headers. It would need about 1000 lines just to list prerequisites for each userland header. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 12:13:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8E4E837B405; Fri, 26 Oct 2001 12:13:34 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id EA71114C2E; Fri, 26 Oct 2001 21:13:32 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bruce Evans Cc: Ruslan Ermilov , Subject: Re: "types" man page References: <20011027044359.H88870-100000@delplex.bde.org> From: Dag-Erling Smorgrav Date: 26 Oct 2001 21:13:32 +0200 In-Reply-To: <20011027044359.H88870-100000@delplex.bde.org> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Bruce Evans writes: > This is a (wrong) implementation detail. [...] Will you ever learn to offer constructive corrections instead of naked criticism? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 12:15:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by hub.freebsd.org (Postfix) with ESMTP id 245BC37B406 for ; Fri, 26 Oct 2001 12:15:14 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by devonshire.cnchost.com id PAA17908; Fri, 26 Oct 2001 15:14:59 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110261914.PAA17908@devonshire.cnchost.com> To: Poul-Henning Kamp Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Fri, 26 Oct 2001 20:34:58 +0200." <5685.1004121298@critter.freebsd.dk> Date: Fri, 26 Oct 2001 12:15:00 -0700 From: Bakul Shah 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 > >Okay, how about this? Define N types that will be > >*exactly* the same on *all* machines: > > > > time_t 32 bits (1 second resolution, upto yr 2038) > > nstime64_t 64 bits (10^-9 second resolution, upto yr 2554) > > Should be 1/2^32 resolution or you have a math nightmare dividing > by 1000000000 all the time. On my 500Mhz PIII it takes about 4.6ns to divide a 64 bit number by a 64 bit 10^9. > > zstime128_t 128 bits (10^-21 second resolution, 10 billion yrs) > > here: resolution 1/2^64 second. > > Decimal computers lost the race and they ain't coming back. We want > arithmetic on binary computers to be fast and simple. Most everyone uses powers of ten for timing units. Remember, millisecond, microsecond, nanosecond, picosecond?! All test equipment time in units of 10s not 2s. That is also why CPUs have clock rate in multiples of 10^6 Hzs not 2^20. It is just being practical even if division by a power of 10 is a bit of a pain. > >BTW, this discussion should be conducted on comp.std.internat > >as it affects all OSes, not just FreeBSD. > > Well, sorry, ENOTIME from here. Well, *someone* from FreeBSD core should be participating. At least tell people there what you are planning to do. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 12:22:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 8216137B403 for ; Fri, 26 Oct 2001 12:22:44 -0700 (PDT) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id f9QJJSW59274; Fri, 26 Oct 2001 12:19:28 -0700 (PDT) (envelope-from dg) Date: Fri, 26 Oct 2001 12:19:28 -0700 From: David Greenman To: Julian Elischer Cc: Poul-Henning Kamp , tlambert2@mindspring.com, Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026121928.D58218@nexus.root.com> References: <20011026100039.C58218@nexus.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from julian@elischer.org on Fri, Oct 26, 2001 at 12:49:59PM -0700 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 >> Any solution that tries to bandaid the problem by using a few bits from >> here or there is unacceptable to me. I have mixed feelings about changing >> to phk's 1/1^64 fractional timestamp idea, but I do think that we should >> make time_t 64 bits on all architectures, including x86, starting with v5 >> of FreeBSD. > >that would be 1/2^64 no? Yes, of course. I originally tried to write it as 1/1<<64, but then thought that sounded convoluted and then promptly screwed it up when I wrote it as a power of two. Anyway, you knew what I meant! :-) -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 12:47:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0665837B403 for ; Fri, 26 Oct 2001 12:47:49 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QJkpM06792; Fri, 26 Oct 2001 21:46:52 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bakul Shah Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 12:15:00 PDT." <200110261914.PAA17908@devonshire.cnchost.com> Date: Fri, 26 Oct 2001 21:46:51 +0200 Message-ID: <6790.1004125611@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110261914.PAA17908@devonshire.cnchost.com>, Bakul Shah writes: >> Decimal computers lost the race and they ain't coming back. We want >> arithmetic on binary computers to be fast and simple. > >Most everyone uses powers of ten for timing units. Remember, >millisecond, microsecond, nanosecond, picosecond?! All test >equipment time in units of 10s not 2s. That is also why CPUs >have clock rate in multiples of 10^6 Hzs not 2^20. It is >just being practical even if division by a power of 10 is a >bit of a pain. Right. Almost everyone uses powers of their monetary units as well, yet they use binary numbers to represent them. The problem is that people tend to think of time as integers instead of a floating point value. 1 second 500 million nanoseconds should not be represented as "1 times foo + 500000000 times bar" it should be represented as "1.5 times foo" The lowest level of timekeeping code in the kernel, the timecounters, need to operate at a level of precision where they can faithfully represent the frequency of whatever hardware we throw at them. Since we accumulate tics, usually at a rate of hz, a resolution of one nanosecond is not enough for frequencies much higher than approx 50 MHz. Our timecounting code already operates with a precision of 32bit fraction of nanoseconds for this reason. In order to support timespec, the chosen format is actually: <--32 bit sec--><--32 bit nsec--><--32bit fractional nsec--> If you look in sys/kern/kern_tc.c you can see how much extra gunk that results in, checking for overruns on the middle part and whats not. There can be no doubt that the best timestamp representation is pure binary, originating at the second, and that is how my proposal is constructed: <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> 1 2 3 4 You can then use whatever subset you want for particular purposes, and not pay an arm and a leg in conversion costs: 2 alone is the same as time_t today 2+3 is enough to convert til timeval/timespec: tv->tv_sec = ts->f2 tv->tv_usec = ((u_int64_t)ts->f3 * 1000000) >> 32; ts->tv_sec = ts->f2 ts->tv_nsec = ((u_int64_t)ts->f3 * 1000000000) >> 32; (no divisions!) 2+3 is identical to NTP timestamps. 1+2 = 64 bit seconds ("time_t_ng") 1+2+3+4 = enough for anything anybody can think of. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 12:48:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep13-int.chello.nl (amsfep13-int.chello.nl [213.46.243.23]) by hub.freebsd.org (Postfix) with ESMTP id 86A5C37B405 for ; Fri, 26 Oct 2001 12:48:14 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep13-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011026194813.WFGH18584.amsfep13-int.chello.nl@daemon.chronias.ninth-circle.org>; Fri, 26 Oct 2001 21:48:13 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9QJl3N02404; Fri, 26 Oct 2001 21:47:03 +0200 (CEST) (envelope-from asmodai) Date: Fri, 26 Oct 2001 21:47:03 +0200 From: Jeroen Ruigrok/Asmodai To: Terry Lambert Cc: Poul-Henning Kamp , Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026214703.K96876@daemon.ninth-circle.org> References: <2912.1004113233@critter.freebsd.dk> <3BD993A6.E6B12512@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BD993A6.E6B12512@mindspring.com> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011026 18:49], Terry Lambert (tlambert2@mindspring.com) wrote: >According to you, that won't bite anyone for 10 years. I have heard arguments like this before. ``The solution is temporary.'' ``But we will replace this with the correct stuff in a few days/weeks/months/years.'' 10 years passes quickly has been my experience and I rather have a good solution than one which fills the gap for 10 years now and that we get this entire revisitation 10 years from now. But that's my personal belief and observations. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ United we stand, divided we fall... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 12:48:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep13-int.chello.nl (amsfep13-int.chello.nl [213.46.243.23]) by hub.freebsd.org (Postfix) with ESMTP id 9F63937B406 for ; Fri, 26 Oct 2001 12:48:14 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep13-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011026194808.WFFJ18584.amsfep13-int.chello.nl@daemon.chronias.ninth-circle.org>; Fri, 26 Oct 2001 21:48:08 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9QJchA02346; Fri, 26 Oct 2001 21:38:43 +0200 (CEST) (envelope-from asmodai) Date: Fri, 26 Oct 2001 21:38:43 +0200 From: Jeroen Ruigrok/Asmodai To: Matthew Jacob Cc: Garance A Drosihn , arch@freebsd.org Subject: Re: 64 bit times revisited.. Message-ID: <20011026213843.J96876@daemon.ninth-circle.org> References: <20011026100750.H68844-100000@wonky.feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026100750.H68844-100000@wonky.feral.com> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011026 19:20], Matthew Jacob (mjacob@feral.com) wrote: >I would expect Intel to in fact *not* push IA-64 for desktop machines- at >least not for several years. Maybe Intel won't push it, but having DEC, nay, Compaq, nay, HP boxen and we need to keep expanding/replacing gear like this we have little choice BUT moving to IA-64. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ When you are right, you cannot be too radical; When you are wrong, you cannot be too conservative. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 12:51:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep14-int.chello.nl (amsfep14-int.chello.nl [213.46.243.21]) by hub.freebsd.org (Postfix) with ESMTP id 770BB37B405 for ; Fri, 26 Oct 2001 12:51:24 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep14-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011026195123.ITMZ25701.amsfep14-int.chello.nl@daemon.chronias.ninth-circle.org>; Fri, 26 Oct 2001 21:51:23 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9QJotI02443; Fri, 26 Oct 2001 21:50:55 +0200 (CEST) (envelope-from asmodai) Date: Fri, 26 Oct 2001 21:50:54 +0200 From: Jeroen Ruigrok/Asmodai To: Poul-Henning Kamp Cc: Alfred Perlstein , Julian Elischer , Terry Lambert , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026215054.L96876@daemon.ninth-circle.org> References: <20011026114249.E15052@elvis.mu.org> <3686.1004114708@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3686.1004114708@critter.freebsd.dk> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011026 18:46], Poul-Henning Kamp (phk@critter.freebsd.dk) wrote: >I'm merely advocating solving the problem and not hacking around it. Something I very much support. Too many bandaids and work-arounds in the I(C)T world as it is nowadays. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ But Time, keeps flowing like a river (on and on)... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 13: 0:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2192D37B401; Fri, 26 Oct 2001 13:00:22 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA08885; Sat, 27 Oct 2001 06:00:15 +1000 Date: Sat, 27 Oct 2001 05:59:18 +1000 (EST) From: Bruce Evans X-X-Sender: To: Dag-Erling Smorgrav Cc: Ruslan Ermilov , Subject: Re: "types" man page In-Reply-To: Message-ID: <20011027055834.L89603-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On 26 Oct 2001, Dag-Erling Smorgrav wrote: > Bruce Evans writes: > > This is a (wrong) implementation detail. [...] > > Will you ever learn to offer constructive corrections instead of naked > criticism? Yes. The corrections were in the part you didn't quote. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 13: 8:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.17]) by hub.freebsd.org (Postfix) with ESMTP id 26B8D37B412 for ; Fri, 26 Oct 2001 13:08:29 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep12-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011026200828.WXOS7460.amsfep12-int.chello.nl@daemon.chronias.ninth-circle.org>; Fri, 26 Oct 2001 22:08:28 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9QJsaq02450; Fri, 26 Oct 2001 21:54:36 +0200 (CEST) (envelope-from asmodai) Date: Fri, 26 Oct 2001 21:54:36 +0200 From: Jeroen Ruigrok/Asmodai To: Lyndon Nerenberg Cc: arch@freebsd.org Subject: Re: your mail Message-ID: <20011026215436.M96876@daemon.ninth-circle.org> References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> <20011026153313.C96876@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026153313.C96876@daemon.ninth-circle.org> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011026 16:00], Jeroen Ruigrok/Asmodai (asmodai@wxs.nl) wrote: >I would sooner prefer the other way around. Have gcc and g++ and have a >knob to not create the gcc -> cc symlink. :) Of course this should read: cc -> gcc symlink -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ In my mind nothing makes sense... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 13:15: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 7FF7137B405 for ; Fri, 26 Oct 2001 13:15:04 -0700 (PDT) Received: (qmail 64466 invoked from network); 26 Oct 2001 20:15:03 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2001 20:15:03 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <6790.1004125611@critter.freebsd.dk> Date: Fri, 26 Oct 2001 13:15:01 -0700 (PDT) From: John Baldwin To: Poul-Henning Kamp Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG, Peter Wemm , Bakul Shah 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 On 26-Oct-01 Poul-Henning Kamp wrote: > In message <200110261914.PAA17908@devonshire.cnchost.com>, Bakul Shah writes: > >>> Decimal computers lost the race and they ain't coming back. We want >>> arithmetic on binary computers to be fast and simple. >> >>Most everyone uses powers of ten for timing units. Remember, >>millisecond, microsecond, nanosecond, picosecond?! All test >>equipment time in units of 10s not 2s. That is also why CPUs >>have clock rate in multiples of 10^6 Hzs not 2^20. It is >>just being practical even if division by a power of 10 is a >>bit of a pain. > > If you look in sys/kern/kern_tc.c you can see how much extra > gunk that results in, checking for overruns on the middle part and > whats not. > > There can be no doubt that the best timestamp representation is > pure binary, originating at the second, and that is how my proposal > is constructed: > > <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> > 1 2 3 4 IOW, a fixed-point number. This is definitely the optimal solution presented so far for the in-kernel time keeping, IMO. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 13:26:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5FDE837B403; Fri, 26 Oct 2001 13:26:49 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id A4CC514C2E; Fri, 26 Oct 2001 22:26:47 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bruce Evans Cc: Ruslan Ermilov , Subject: Re: "types" man page References: <20011027055834.L89603-100000@delplex.bde.org> From: Dag-Erling Smorgrav Date: 26 Oct 2001 22:26:47 +0200 In-Reply-To: <20011027055834.L89603-100000@delplex.bde.org> Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Bruce Evans writes: > On 26 Oct 2001, Dag-Erling Smorgrav wrote: > > Bruce Evans writes: > > > This is a (wrong) implementation detail. [...] > > Will you ever learn to offer constructive corrections instead of naked > > criticism? > Yes. The corrections were in the part you didn't quote. Sorry about that outbreak, but you do tend to lecture. A simple "this should say X instead of Y" would suffice. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 13:40:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 294FD37B408; Fri, 26 Oct 2001 13:40:18 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA10715; Sat, 27 Oct 2001 06:40:12 +1000 Date: Sat, 27 Oct 2001 06:39:05 +1000 (EST) From: Bruce Evans X-X-Sender: To: Bill Fenner Cc: , , Subject: Re: Behavior of select() on pipes In-Reply-To: <200110252343.QAA28072@windsor.research.att.com> Message-ID: <20011027061249.K89650-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 25 Oct 2001, Bill Fenner wrote: > IEEE Std 1003.1-200x says, about select: > > A descriptor shall be considered ready for reading when a call > to an input function with O_NONBLOCK clear would not block, > whether or not the function would transfer data successfully. Good. I couldn't find this section when I checked this recently after further followup to the PR. I still can't find a section that gives as much detail for poll(). A poll on POLLIN succeeds when "Data other than high priority data can be read without blocking". > and about read: > > When attempting to read from an empty pipe or FIFO: > > * If no process has the pipe open for writing, read( ) > shall return 0 to indicate end-of-file. > > This combination says to me that select() should consider a FIFO with shall :-) > no writers to be readable. This makes sense when it's been open and > the writer closes it, as you need to read the EOF, but doesn't make > as much sense when it hasn't been opened for write yet. > > Perhaps we can carefully interpret "an empty .. FIFO" to exclude the > time before the first writer opens it. Maybe during that time it's not > empty, it's untenanted. Ugh. It makes sense for the state not to depend on previous activity. It reduces the effect of races. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 13:45:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4D51B37B403 for ; Fri, 26 Oct 2001 13:45:09 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9QKirg17919; Fri, 26 Oct 2001 13:44:53 -0700 (PDT) (envelope-from obrien) Date: Fri, 26 Oct 2001 13:44:53 -0700 From: "David O'Brien" To: Garance A Drosihn Cc: Matthew Dillon , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026134453.B17758@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Fri, Oct 26, 2001 at 01:29:53PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Fri, Oct 26, 2001 at 01:29:53PM -0400, Garance A Drosihn wrote: > At 5:47 PM -0700 10/25/01, Matthew Dillon wrote: > >:I vote for option (3), 64-bit time_t for all 64 bit architectures. > >:I would go along with option (4) provided that the change-over came > >:with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > > > > I agree completely. 64 bit time_t for all 64 bit archs, and > > frankly I would also like to see a 64 bit time_t for 5.x on 32 > > bit archs... lets get the pain over and done with now rather > > then later. > > Let me waste a few electrons by also agreeing to this general > direction. We are hoping to bring on new platforms of sparc64 > and ia-64 for the 5.0-timeframe (or certainly before the 6.0 > timeframe). It would be exceedingly stupid to start out those > 64-bit platforms on 32-bit time_t's, when we KNOW we will have > switch to 64-bit times at some later point. So, I would put in > a very strong, pound-the-table vote for 64-bit time_t on 64-bit > architectures. I disagree. I have experience trying to run our "lesser" [used] platform, most of you do not. Keeping things bug-for-bug and "feature"-for-"feature" identical is important. > Given 64-bit time_t's for the new platforms, we might as well go > for 64-bit times on all platforms (although we obviously can > not MFC that back into the 4.x-branch for 32-bit platforms). I > don't feel quite so strongly about 64-bit time_t's on 32-bit > architectures, but it does seem like the right thing to do. 64-bit for FreeBSD or 32-bit for FreeBSD. No 1/2's please. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14: 8:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7B00437B403; Fri, 26 Oct 2001 14:08:50 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QL8n238592; Fri, 26 Oct 2001 14:08:49 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 14:08:49 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262108.f9QL8n238592@apollo.backplane.com> To: John Baldwin Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: 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 :> :> If you look in sys/kern/kern_tc.c you can see how much extra :> gunk that results in, checking for overruns on the middle part and :> whats not. :> :> There can be no doubt that the best timestamp representation is :> pure binary, originating at the second, and that is how my proposal :> is constructed: :> :> <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> :> 1 2 3 4 : :IOW, a fixed-point number. This is definitely the optimal solution presented :so far for the in-kernel time keeping, IMO. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ Not. Not exactly, anyway. A base-2 fractional representation will introduce serious rounding errors for anyone doing any sort of arithmatic. For example, the representation of a nanosecond is 2^64/1E9 = 18,446,744,073.7. If you add two 1 nanosecond values together, you don't get 2 ns. A base-10 fractional representation (1.0E+19) rather then 2^64 is almost certainly going to be a better all-around representation. In that case 1nS winds up being 1E19/1E9 = 1E10. 1 picosecond winds up being 1E7, and so forth. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:13:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 41DE637B406; Fri, 26 Oct 2001 14:13:12 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QLDBJ38657; Fri, 26 Oct 2001 14:13:11 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 14:13:11 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262113.f9QLDBJ38657@apollo.backplane.com> To: John Baldwin , Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: <200110262108.f9QL8n238592@apollo.backplane.com> 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 : : ::> ::> If you look in sys/kern/kern_tc.c you can see how much extra ::> gunk that results in, checking for overruns on the middle part and ::> whats not. ::> ::> There can be no doubt that the best timestamp representation is ::> pure binary, originating at the second, and that is how my proposal ::> is constructed: ::> ::> <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> ::> 1 2 3 4 :: ::IOW, a fixed-point number. This is definitely the optimal solution presented ::so far for the in-kernel time keeping, IMO. And I will also note that trying to represent both seconds and sub-seconds in a single fixed point integer is a real bad idea. It makes life unnecessarily difficult for the 95% of the code that only needs the seconds portion. Any fractional representation should be a SEPARATE field. We will have time_t, in seconds, and we can have struct ntm representing both the seconds and fractional portions (as separate fields). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:18: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8401A37B401; Fri, 26 Oct 2001 14:17:55 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QLHGM08188; Fri, 26 Oct 2001 23:17:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 14:08:49 PDT." <200110262108.f9QL8n238592@apollo.backplane.com> Date: Fri, 26 Oct 2001 23:17:16 +0200 Message-ID: <8186.1004131036@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110262108.f9QL8n238592@apollo.backplane.com>, Matthew Dillon wri tes: >:> There can be no doubt that the best timestamp representation is >:> pure binary, originating at the second, and that is how my proposal >:> is constructed: >:> >:> <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> >:> 1 2 3 4 >: >:IOW, a fixed-point number. This is definitely the optimal solution presented >:so far for the in-kernel time keeping, IMO. >: >:-- >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ > > Not. Not exactly, anyway. A base-2 fractional representation will > introduce serious rounding errors for anyone doing any sort of arithmatic. > For example, the representation of a nanosecond is 2^64/1E9 = > 18,446,744,073.7. If you add two 1 nanosecond values together, you don't > get 2 ns. I think I see your anti-phk reflex kick in here, but let me answer anyway: Any physicist or engineer knows something about "significant digits" and that applies here as well. You don't add two nanoseconds together. If your numbers are in that range, you add some multiple of 1/2^64 s together, and the rounding errors will be totally insignificant. Nothing in your computer happens in multiple of nano-seconds, it happens in multiple of clock cycles. Modern clockcycles hate nanoseconds: 1400 MHz = .714285... nsec > A base-10 fractional representation (1.0E+19) rather then 2^64 is > almost certainly going to be a better all-around representation. > In that case 1nS winds up being 1E19/1E9 = 1E10. 1 picosecond winds > up being 1E7, and so forth. There is only one problems: it will make everything slower because computers are binary: any conversion to get seconds will cost you a (long) division, which is still 30 times more expensive than a multiplication. Computers are binary and work best in binary. Time is a floating point unit (as far as physics have been able to make out, it could be rational though) -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:23:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8395137B406; Fri, 26 Oct 2001 14:23:06 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QLMWM08308; Fri, 26 Oct 2001 23:22:32 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 14:13:11 PDT." <200110262113.f9QLDBJ38657@apollo.backplane.com> Date: Fri, 26 Oct 2001 23:22:32 +0200 Message-ID: <8306.1004131352@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110262113.f9QLDBJ38657@apollo.backplane.com>, Matthew Dillon wri tes: > >: >: >::> >::> If you look in sys/kern/kern_tc.c you can see how much extra >::> gunk that results in, checking for overruns on the middle part and >::> whats not. >::> >::> There can be no doubt that the best timestamp representation is >::> pure binary, originating at the second, and that is how my proposal >::> is constructed: >::> >::> <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> >::> 1 2 3 4 >:: >::IOW, a fixed-point number. This is definitely the optimal solution presented >::so far for the in-kernel time keeping, IMO. > > And I will also note that trying to represent both seconds and sub-seconds > in a single fixed point integer is a real bad idea. It makes life > unnecessarily difficult for the 95% of the code that only needs the > seconds portion. Any fractional representation should be a SEPARATE > field. Matt, From binary math 101: u_int128_t x; time_t sec; x = gettime(); /* units = 1/2^64 */ sec = x >> 64; It cannot possibly be simpler... You _really_ need to loose that anti-phk reflex of yours. > We will have time_t, in seconds, and we can have struct ntm representing > both the seconds and fractional portions (as separate fields). ARGH! that is exactly the timespec braindamage I'm trying to avoid! grep sys/kern for 100000{000} if you want to see what the problem is :-( -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:23:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id A59E237B408; Fri, 26 Oct 2001 14:23:19 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id E84404CE42; Fri, 26 Oct 2001 17:23:18 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA24510; Fri, 26 Oct 2001 17:23:18 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA13087; Fri, 26 Oct 2001 14:23:17 -0700 (PDT) Message-Id: <200110262123.OAA13087@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bde@zeta.org.au Subject: Re: Behavior of select() on pipes Cc: rwatson@freebsd.org, bright@mu.org, arch@freebsd.org Date: Fri, 26 Oct 2001 14:23:17 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b 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 Yes, it's a shame that the description of select() carefully covers this case and it's completely missing from poll(). >> Perhaps we can carefully interpret "an empty .. FIFO" to exclude the >> time before the first writer opens it. Maybe during that time it's not >> empty, it's untenanted. > >Ugh. It makes sense for the state not to depend on previous activity. >It reduces the effect of races. But the standard behavior makes O_NONBLOCK FIFOs relatively useless; once you open it for read you have no way to find out when a writer arrives without blocking. You have to become a writer yourself, which may limit the usefulness of permissions on the FIFO (e.g. an rw-r----- FIFO for messages from fenner to group foo; anyone in group foo could become the reader but it's impossible for them to open for writing to get around this behavior). Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:24:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id AE3BE37B406 for ; Fri, 26 Oct 2001 14:24:10 -0700 (PDT) Received: (qmail 39084 invoked from network); 26 Oct 2001 21:24:09 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2001 21:24:09 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200110262113.f9QLDBJ38657@apollo.backplane.com> Date: Fri, 26 Oct 2001 14:24:07 -0700 (PDT) From: John Baldwin To: Matthew Dillon Subject: Re: 64 bit times revisited.. Cc: Bakul Shah , Peter Wemm , arch@FreeBSD.ORG, Poul-Henning Kamp 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 On 26-Oct-01 Matthew Dillon wrote: > >: >: >::> >::> If you look in sys/kern/kern_tc.c you can see how much extra >::> gunk that results in, checking for overruns on the middle part and >::> whats not. >::> >::> There can be no doubt that the best timestamp representation is >::> pure binary, originating at the second, and that is how my proposal >::> is constructed: >::> >::> <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> >::> 1 2 3 4 >:: >::IOW, a fixed-point number. This is definitely the optimal solution >::presented >::so far for the in-kernel time keeping, IMO. > > And I will also note that trying to represent both seconds and sub-seconds > in a single fixed point integer is a real bad idea. It makes life > unnecessarily difficult for the 95% of the code that only needs the > seconds portion. Any fractional representation should be a SEPARATE > field. Err it is a separate field. You have a 128-bit counter. The high 64-bits are the seconds portion. You just shift to get the seconds. This is not hard. Computers have been good at doing shift right's for quite some time now. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:25: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BE40737B405; Fri, 26 Oct 2001 14:25:03 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QLP0u38719; Fri, 26 Oct 2001 14:25:00 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 14:25:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262125.f9QLP0u38719@apollo.backplane.com> To: Poul-Henning Kamp Cc: John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: <8186.1004131036@critter.freebsd.dk> 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 :> For example, the representation of a nanosecond is 2^64/1E9 = :> 18,446,744,073.7. If you add two 1 nanosecond values together, you don't :> get 2 ns. : :I think I see your anti-phk reflex kick in here, but let me answer anyway: : :Any physicist or engineer knows something about "significant digits" :and that applies here as well. You don't add two nanoseconds :together. If your numbers are in that range, you add some multiple :of 1/2^64 s together, and the rounding errors will be totally :insignificant. This isn't how it works, Poul. FP implementations which use base-2 representations actually calculate an extra digit (at a minimum), and quite often much more then that, and then round the result that you see. Even base-10 representations do that, though they don't need to for a certain subset of operations such as addition and subtraction (which are the most common). Unless you intend to do the same manually for EVERY SINGLE OPERATION you do with your fixed point representation, you've just screwed us. This is not physics we are talking about, it is basic math. The computer may be base-2, but humans are base-10. If you are going to introduce a numerical system that is either (1) always generates errors for both human manipulation and machine representations or (2) only generates errors for machine representations, then (2) is the better choice. The only completely correct machine representation is 'clock cycles' or 'ticks'. Great... but not portable, so we can't use it unless we introduce a whole new way of thinking. And even then we are screwed because now the user cannot depend on a minimum level of precision (even if it winds up only being statistically aggregated precision). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:28:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A1D7D37B405; Fri, 26 Oct 2001 14:28:33 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QLSX838762; Fri, 26 Oct 2001 14:28:33 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 14:28:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262128.f9QLSX838762@apollo.backplane.com> To: John Baldwin Cc: Bakul Shah , Peter Wemm , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: 64 bit times revisited.. References: 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 :>::so far for the in-kernel time keeping, IMO. :> :> And I will also note that trying to represent both seconds and sub-seconds :> in a single fixed point integer is a real bad idea. It makes life :> unnecessarily difficult for the 95% of the code that only needs the :> seconds portion. Any fractional representation should be a SEPARATE :> field. : :Err it is a separate field. You have a 128-bit counter. The high 64-bits are :the seconds portion. You just shift to get the seconds. This is not hard. :Computers have been good at doing shift right's for quite some time now. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ The phrase 'no freaking way' comes to mind. You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing else. The *VAST* majority of programs only need seconds, it would be utterly stupid to require that they mess around with some weird fixed point quantity when all they want is seconds, no matter how supposedly 'simple' that messing around is (i.e. '>> 64' is not acceptable). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:34:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 466C837B403; Fri, 26 Oct 2001 14:34:46 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QLYDM08631; Fri, 26 Oct 2001 23:34:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: John Baldwin , Bakul Shah , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 14:28:33 PDT." <200110262128.f9QLSX838762@apollo.backplane.com> Date: Fri, 26 Oct 2001 23:34:13 +0200 Message-ID: <8629.1004132053@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110262128.f9QLSX838762@apollo.backplane.com>, Matthew Dillon wri tes: > >:>::so far for the in-kernel time keeping, IMO. >:> >:> And I will also note that trying to represent both seconds and sub-seconds >:> in a single fixed point integer is a real bad idea. It makes life >:> unnecessarily difficult for the 95% of the code that only needs the >:> seconds portion. Any fractional representation should be a SEPARATE >:> field. >: >:Err it is a separate field. You have a 128-bit counter. The high 64-bits are >:the seconds portion. You just shift to get the seconds. This is not hard. >:Computers have been good at doing shift right's for quite some time now. >: >:-- >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ > > The phrase 'no freaking way' comes to mind. > > You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing > else. The *VAST* majority of programs only need seconds, it would be > utterly stupid to require that they mess around with some weird fixed > point quantity when all they want is seconds, no matter how supposedly > 'simple' that messing around is (i.e. '>> 64' is not acceptable). [ For the record: I spent the better part of a two years on making FreeBSD the first UNIX to truly deal with nanoseconds and the first platform where NTP could work in nanoseconds, so I happen to think that I know something about this subject. I'm not going to ignore Matt on this subject until he comes to his senses or at least calms down to the point where he spends more than 3 seconds on an email before replying to it. Obviously my silence should not be interpreted to mean that I have been convinced by and agree with Matt. I maintain my recommandation on 64.64 binary timestamps as our fundamental representation. ] -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:35: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id CC1C937B407 for ; Fri, 26 Oct 2001 14:34:51 -0700 (PDT) Received: (qmail 44213 invoked from network); 26 Oct 2001 21:34:51 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2001 21:34:51 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200110262128.f9QLSX838762@apollo.backplane.com> Date: Fri, 26 Oct 2001 14:34:48 -0700 (PDT) From: John Baldwin To: Matthew Dillon Subject: Re: 64 bit times revisited.. Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah 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 On 26-Oct-01 Matthew Dillon wrote: > >:>::so far for the in-kernel time keeping, IMO. >:> >:> And I will also note that trying to represent both seconds and >:> sub-seconds >:> in a single fixed point integer is a real bad idea. It makes life >:> unnecessarily difficult for the 95% of the code that only needs the >:> seconds portion. Any fractional representation should be a SEPARATE >:> field. >: >:Err it is a separate field. You have a 128-bit counter. The high 64-bits >:are >:the seconds portion. You just shift to get the seconds. This is not hard. >:Computers have been good at doing shift right's for quite some time now. >: >:-- >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ > > The phrase 'no freaking way' comes to mind. > > You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing > else. The *VAST* majority of programs only need seconds, it would be > utterly stupid to require that they mess around with some weird fixed > point quantity when all they want is seconds, no matter how supposedly > 'simple' that messing around is (i.e. '>> 64' is not acceptable). > > -Matt Umm. Dude, this is for the kernel's internal representations. We can massage it in libc or in the kernel before it gets to userland. We do have to maintain compatibility. Slow down and think about this for a second. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:37:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C102A37B401; Fri, 26 Oct 2001 14:37:30 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QLavM08702; Fri, 26 Oct 2001 23:36:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) Cc: Matthew Dillon , John Baldwin , Bakul Shah , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 23:34:13 +0200." <8629.1004132053@critter.freebsd.dk> Date: Fri, 26 Oct 2001 23:36:57 +0200 Message-ID: <8700.1004132217@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <8629.1004132053@critter.freebsd.dk>, Poul-Henning Kamp writes: Damn, signbug: >[ > >For the record: > >I spent the better part of a two years on making FreeBSD the first >UNIX to truly deal with nanoseconds and the first platform where NTP >could work in nanoseconds, so I happen to think that I know something >about this subject. > >I'm not going to ignore Matt on this subject until he comes to his s/not // >senses or at least calms down to the point where he spends more than >3 seconds on an email before replying to it. > >Obviously my silence should not be interpreted to mean that I >have been convinced by and agree with Matt. > >I maintain my recommandation on 64.64 binary timestamps as our >fundamental representation. > >] > > > >-- >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 freebsd-arch" in the body of the message > -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:44:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5EDBB37B401 for ; Fri, 26 Oct 2001 14:44:23 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9QLi4J55186 for ; Fri, 26 Oct 2001 17:44:04 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011026134453.B17758@dragon.nuxi.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <20011026134453.B17758@dragon.nuxi.com> Date: Fri, 26 Oct 2001 17:44:01 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 1:44 PM -0700 10/26/01, David O'Brien wrote: >On Fri, Oct 26, 2001 at 01:29:53PM -0400, Garance A Drosihn wrote: > > We are hoping to bring on new platforms of sparc64 > > and ia-64 for the 5.0-timeframe (or certainly before the 6.0 >> timeframe). It would be exceedingly stupid to start out those >> 64-bit platforms on 32-bit time_t's, when we KNOW we will have > > switch to 64-bit times at some later point. > >I disagree. I have experience trying to run our "lesser" [used] >platform, most of you do not. Keeping things bug-for-bug and >"feature"-for-"feature" identical is important. Once sparc64 shows up, I'll be getting just as much experience as you will... Same for PowerPC. (which is to say, I plan to run FreeBSD on three hardware architectures, one of which will be 64-bit). > > Given 64-bit time_t's for the new platforms, we might as well go >> for 64-bit times on all platforms (although we obviously can > > not MFC that back into the 4.x-branch for 32-bit platforms). > > I don't feel quite so strongly about 64-bit time_t's on 32-bit > > architectures, but it does seem like the right thing to do. > >64-bit for FreeBSD or 32-bit for FreeBSD. No 1/2's please. I suspect we just have slightly different priorities... I'll pound the table for 64-bit on 64-bit (particularly for all those new platforms), and merely vote yes for 64-bit on 32-bit. You can give a lukewarm vote of yes for 64-bit on 64-bit, and then pound the table that time_t should be the same on all platforms... Seems like we should be able to come up with an agreeable solution here! :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:47:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D6CC937B403; Fri, 26 Oct 2001 14:47:19 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QLlJ838887; Fri, 26 Oct 2001 14:47:19 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 14:47:19 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262147.f9QLlJ838887@apollo.backplane.com> To: John Baldwin Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: 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 :> The phrase 'no freaking way' comes to mind. :> :> You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing :> else. The *VAST* majority of programs only need seconds, it would be :> utterly stupid to require that they mess around with some weird fixed :> point quantity when all they want is seconds, no matter how supposedly :> 'simple' that messing around is (i.e. '>> 64' is not acceptable). :> :> -Matt : :Umm. Dude, this is for the kernel's internal representations. We can massage :it in libc or in the kernel before it gets to userland. We do have to maintain :compatibility. Slow down and think about this for a second. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ The best kernel-internal time representnation is ticks, with a simple baseline cache mechanism to convert it to other formats (e.g. as required by NFS, UFS, userland, etc...). Nothing beats ticks... a binary fixed point format doesn't even come *close* to being better then straight ticks. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:48:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 7F26B37B401 for ; Fri, 26 Oct 2001 14:48:34 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9QLmXM45486 for ; Fri, 26 Oct 2001 14:48:33 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 5C3E4380A; Fri, 26 Oct 2001 14:48:33 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: David Greenman Cc: Julian Elischer , Poul-Henning Kamp , tlambert2@mindspring.com, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011026100039.C58218@nexus.root.com> Date: Fri, 26 Oct 2001 14:48:33 -0700 From: Peter Wemm Message-Id: <20011026214833.5C3E4380A@overcee.netplex.com.au> 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 David Greenman wrote: > >but here;s a better idea anyhow.. > > > >take the TOP 2 bits.. they can never be used now anyhow.... > >that gives us nanosecond resolution, which is all we can report now > >anyway, and multiplies the seconds range by 4. Assuming that we do not > >allow access times < 1970 on disk (there were no such files then, > >then we are ok up to the year 2600, by which time we hope there are no > >embededded systems from the next 5 years still running..... > > Any solution that tries to bandaid the problem by using a few bits from > here or there is unacceptable to me. I have mixed feelings about changing > to phk's 1/1^64 fractional timestamp idea, but I do think that we should > make time_t 64 bits on all architectures, including x86, starting with v5 > of FreeBSD. > > -DG I certainly agree with the dislike of using bandaids, bits or hacks. Kirk is refreshing FFS, which sounds like it solves the problem nicely. FFS should not be an issue here. The other on-disk formats need a type-safe definition, and thats all there is to it. We can incrementally introduce 64 bit time support there at our leisure. pwd.db, for example, is easy. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:50:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 42C8337B406; Fri, 26 Oct 2001 14:50:23 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QLoMB38937; Fri, 26 Oct 2001 14:50:22 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 14:50:22 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262150.f9QLoMB38937@apollo.backplane.com> To: John Baldwin , Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: 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 : The best kernel-internal time representnation is ticks, with a simple : baseline cache mechanism to convert it to other formats (e.g. as : required by NFS, UFS, userland, etc...). Nothing beats ticks... : a binary fixed point format doesn't even come *close* to being better : then straight ticks. : -Matt Before this gets misinterpreted, the 'ticks' I am talking about is not the kernel timer interrupt ticks... it's the high resolution cpu or 825x ticks we get. e.g. frequency dependant on the timer we use. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:51: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id AA8EB37B403; Fri, 26 Oct 2001 14:51:01 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9QLp1b75389; Fri, 26 Oct 2001 17:51:01 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 17:51:01 -0400 (EDT) From: Garrett Wollman Message-Id: <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> To: obrien@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011026134453.B17758@dragon.nuxi.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> Organization: MIT Laboratory for Computer Science Cc: 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 In article <20011026134453.B17758@dragon.nuxi.com> you write: >64-bit for FreeBSD or 32-bit for FreeBSD. No 1/2's please. Are you prepared to do the work to ensure that `long' is the same width on all FreeBSD architectures? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 14:59:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep15-int.chello.nl (amsfep15-int.chello.nl [213.46.243.27]) by hub.freebsd.org (Postfix) with ESMTP id 1FC8037B401; Fri, 26 Oct 2001 14:59:25 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep15-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011026215923.KIMP14265.amsfep15-int.chello.nl@daemon.chronias.ninth-circle.org>; Fri, 26 Oct 2001 23:59:23 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9QLx7h03881; Fri, 26 Oct 2001 23:59:07 +0200 (CEST) (envelope-from asmodai) Date: Fri, 26 Oct 2001 23:59:07 +0200 From: Jeroen Ruigrok/Asmodai To: Garrett Wollman Cc: obrien@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026235906.Q96876@daemon.ninth-circle.org> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011026 23:55], Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: >Are you prepared to do the work to ensure that `long' is the same >width on all FreeBSD architectures? Wouldn't that go against the idea of ILP32 versus LP64? [Which is, for all I know, what most 32-bit, respectively 64-bitCPUs follow for their datatypes] -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honors the servant and has forgotten the gift... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15: 1:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 3AEF437B401; Fri, 26 Oct 2001 15:01:40 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QM16M09135; Sat, 27 Oct 2001 00:01:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 14:50:22 PDT." <200110262150.f9QLoMB38937@apollo.backplane.com> Date: Sat, 27 Oct 2001 00:01:06 +0200 Message-ID: <9133.1004133666@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110262150.f9QLoMB38937@apollo.backplane.com>, Matthew Dillon wri tes: > >: The best kernel-internal time representnation is ticks, with a simple >: baseline cache mechanism to convert it to other formats (e.g. as >: required by NFS, UFS, userland, etc...). Nothing beats ticks... >: a binary fixed point format doesn't even come *close* to being better >: then straight ticks. >: > > Before this gets misinterpreted, the 'ticks' I am talking about is > not the kernel timer interrupt ticks... it's the high resolution cpu > or 825x ticks we get. e.g. frequency dependant on the timer we use. Matt, that is the mess Linux is fighting with. We have had a superior solution for years by now which even allows us to change timekeeping hardware on the fly as we find more suitable timebases. -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15: 3:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B1F9F37B405 for ; Fri, 26 Oct 2001 15:03:31 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 7463A14C2E; Sat, 27 Oct 2001 00:03:30 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Kirk McKusick Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> From: Dag-Erling Smorgrav Date: 27 Oct 2001 00:03:29 +0200 In-Reply-To: Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Dag-Erling Smorgrav writes: > FWIW, I add my vote to this option. There seems to be some confusion as to what I meant, so let me reword: I am in favor of switching time_t to 64-bit on *all* platforms in 5-CURRENT, and leaving 4-STABLE alone. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15: 9:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id EA9C937B401 for ; Fri, 26 Oct 2001 15:09:52 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9QM9on75561; Fri, 26 Oct 2001 18:09:50 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 18:09:50 -0400 (EDT) From: Garrett Wollman Message-Id: <200110262209.f9QM9on75561@khavrinen.lcs.mit.edu> To: asmodai@wxs.nl Subject: Re: 64 bit times revisited.. X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20011026235906.Q96876@daemon.ninth-circle.org> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org 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 In article <20011026235906.Q96876@daemon.ninth-circle.org> you write: >-On [20011026 23:55], Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: >>Are you prepared to do the work to ensure that `long' is the same >>width on all FreeBSD architectures? > >Wouldn't that go against the idea of ILP32 versus LP64? You have stumbled upon the point! David's argument is entirely specious: there are 32-bit processors, and there are 64-bit processors, and data types should be selected which are appropriate for the processor. There may well be good reasons for wanting a specific type (time_t) to have a specific range, but to suggest that it is inherently bad for types generally to have different definitions on different architectures is specious. If we care about compatibility with ISO 9899:1990 (Standard C 1990 edition), time_t is restricted to be no longer than `long'. By the way, POSIX specifies that time_t may be an integer or real-floating type. However, elsewhere it specifies a particular meaning which implies that the fractional part must always be zero. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:10: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id EB90537B401; Fri, 26 Oct 2001 15:10:01 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QM9m739133; Fri, 26 Oct 2001 15:09:48 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 15:09:48 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262209.f9QM9m739133@apollo.backplane.com> To: Poul-Henning Kamp Cc: John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: <9133.1004133666@critter.freebsd.dk> 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 :> Before this gets misinterpreted, the 'ticks' I am talking about is :> not the kernel timer interrupt ticks... it's the high resolution cpu :> or 825x ticks we get. e.g. frequency dependant on the timer we use. : :Matt, that is the mess Linux is fighting with. We have had a superior :solution for years by now which even allows us to change timekeeping :hardware on the fly as we find more suitable timebases. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I don't consider our solution to be superior, I consider it to be a huge mess. It's a huge hack to deal with i386-specific time counter issues and, frankly, it doesn't even do that good a job at it. We've been plagued by backwards-time notifications and weird things happening for YEARS now. It is far too sensitive to environmental conditions like laptops going into sleep mode and such. One unbelievably large mess. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:11:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8244B37B44B; Fri, 26 Oct 2001 15:11:22 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA12665; Fri, 26 Oct 2001 16:25:10 -0700 (PDT) Date: Fri, 26 Oct 2001 16:25:09 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: John Baldwin , Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. In-Reply-To: <200110262147.f9QLlJ838887@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 trouble is, that ticks are: 1: not guaranteed to be constant 2/ inaccurate. also, you can represent ticks in terms of 1/(2^64) units, certainly to the accuracy of the crystals that we use for timekeeping at this time. On Fri, 26 Oct 2001, Matthew Dillon wrote: > > :> The phrase 'no freaking way' comes to mind. > :> > :> You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing > :> else. The *VAST* majority of programs only need seconds, it would be > :> utterly stupid to require that they mess around with some weird fixed > :> point quantity when all they want is seconds, no matter how supposedly > :> 'simple' that messing around is (i.e. '>> 64' is not acceptable). > :> > :> -Matt > : > :Umm. Dude, this is for the kernel's internal representations. We can massage > :it in libc or in the kernel before it gets to userland. We do have to maintain > :compatibility. Slow down and think about this for a second. > : > :-- > : > :John Baldwin -- http://www.FreeBSD.org/~jhb/ > > The best kernel-internal time representnation is ticks, with a simple > baseline cache mechanism to convert it to other formats (e.g. as > required by NFS, UFS, userland, etc...). Nothing beats ticks... > a binary fixed point format doesn't even come *close* to being better > then straight ticks. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:11:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E7FF137B434; Fri, 26 Oct 2001 15:11:36 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA12657; Fri, 26 Oct 2001 16:20:14 -0700 (PDT) Date: Fri, 26 Oct 2001 16:20:12 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: John Baldwin , Bakul Shah , Peter Wemm , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: 64 bit times revisited.. In-Reply-To: <200110262128.f9QLSX838762@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 geez, guys if you all preceeded your comments by "In my opinion" or "It seems to me that ..." we'd get less agro here. Here are some random thoughts.. Often, just the seconds are needed, a 128 but fixed point value can be replresented by 2 x 64bit values, and there is no need to read the fractional part. Things that are going to want decimal are destined for humans. In that case it seems to me that other formatting that will be going on will mask the time needed to do a decimal conversion. Humans probably don't care about the picosecond parts anyhow. With a 64 bit mantissa, a nanosecond acn be expressed to an accuracy of 1 part in 16 billion. that's certainly close enough for me, considering the accuracey of timesources.. I would put it that possibly, if we look at the options, that the internal time reference could be best represented by 64 bits of second and 64 bits of 1/(2^64)th of a second. Constants of mSecs, uSecs, uSecs can be easily given to an accuracy that will cover all human scale concerns. When needed this can be treated as a single 128 bit number, or a single 64 bit number of seconds, with no conversions needed. I can't really think of places where the kernel internal representation of time needs to be accessed as a decimal number except for file timestamps (and that's only if they are defined that way). Certainly not cases that are really time critical. I think that when programs look for such things the interface can convert. Julian On Fri, 26 Oct 2001, Matthew Dillon wrote: > > :>::so far for the in-kernel time keeping, IMO. > :> > :> And I will also note that trying to represent both seconds and sub-seconds > :> in a single fixed point integer is a real bad idea. It makes life > :> unnecessarily difficult for the 95% of the code that only needs the > :> seconds portion. Any fractional representation should be a SEPARATE > :> field. > : > :Err it is a separate field. You have a 128-bit counter. The high 64-bits are > :the seconds portion. You just shift to get the seconds. This is not hard. > :Computers have been good at doing shift right's for quite some time now. > : > :-- > : > :John Baldwin -- http://www.FreeBSD.org/~jhb/ > > The phrase 'no freaking way' comes to mind. > > You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing > else. The *VAST* majority of programs only need seconds, it would be > utterly stupid to require that they mess around with some weird fixed > point quantity when all they want is seconds, no matter how supposedly > 'simple' that messing around is (i.e. '>> 64' is not acceptable). > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:16: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 0EAAD37B403; Fri, 26 Oct 2001 15:16:03 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9QMSZv04542; Fri, 26 Oct 2001 15:28:35 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110262228.f9QMSZv04542@mass.dis.org> To: Matthew Dillon Cc: Poul-Henning Kamp , John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Matthew Dillon of "Fri, 26 Oct 2001 15:09:48 PDT." <200110262209.f9QM9m739133@apollo.backplane.com> Date: Fri, 26 Oct 2001 15:28:35 -0700 From: Mike Smith 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 > > :> Before this gets misinterpreted, the 'ticks' I am talking about is > :> not the kernel timer interrupt ticks... it's the high resolution cpu > :> or 825x ticks we get. e.g. frequency dependant on the timer we use. > : > :Matt, that is the mess Linux is fighting with. We have had a superior > :solution for years by now which even allows us to change timekeeping > :hardware on the fly as we find more suitable timebases. > > I don't consider our solution to be superior, I consider it to be a > huge mess. It's a huge hack to deal with i386-specific time counter > issues and, frankly, it doesn't even do that good a job at it. Actually, this isn't true at all. It's a fairly neat solution to the requirement that we have largely MI timekeeping. > We've > been plagued by backwards-time notifications and weird things happening > for YEARS now. This is a combination if implementation issues and flat-out broken hardware. > It is far too sensitive to environmental conditions > like laptops going into sleep mode and such. One unbelievably large > mess. Again, these are implementation issues, and shouldn't be confused with the basic design which is actually quite sound. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:21:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C7D8737B403; Fri, 26 Oct 2001 15:21:40 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QMKqS00615; Sat, 27 Oct 2001 00:20:53 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Matthew Dillon , John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 16:25:09 PDT." Date: Sat, 27 Oct 2001 00:20:52 +0200 Message-ID: <613.1004134852@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message , Ju lian Elischer writes: >trouble is, that ticks are: >1: not guaranteed to be constant >2/ inaccurate. > >also, >you can represent ticks in terms of 1/(2^64) units, certainly to the >accuracy of the crystals that we use for timekeeping at this time. The 1/(10^9 * 2^32) resolution we have now would allow us to track the NIST Cesium fountain with about a factor of at least 50 to spare (we're still not sure just how good the fountain actually is: what do you compare the worlds best clock to ? :-) 1/(2^64) would increase that to a safety factor of at least 185. I have successfully been able to measure the effect of turning my HP5061 Cesium 90 degrees using our current code (changes the direction of the earths magnetic field on the cesium beam), and that is an effect down in the 1/10^14 range. I'm pretty sure no crystal will give you any trouble :-) -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:26:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8635037B403; Fri, 26 Oct 2001 15:26:29 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QMPta39239; Fri, 26 Oct 2001 15:25:55 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 15:25:55 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262225.f9QMPta39239@apollo.backplane.com> To: Julian Elischer Cc: John Baldwin , Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: 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 : :trouble is, that ticks are: :1: not guaranteed to be constant :2/ inaccurate. : :also, :you can represent ticks in terms of 1/(2^64) units, certainly to the :accuracy of the crystals that we use for timekeeping at this time. It doesn't work. That is, it *might* appear to work if a tick is an 8254 (in the microsecond range), but you wind up with a completely non-deterministic error creep that depends entirely on the frequency. The higher the frequency, the more pronounced the error. If you are trying to sync a microtime style aggregation by using the 1/(2^64) fractional format you wind up adding an error, even if it is small, every single time you call microtime(). The more often you call microtime(), the more pronounced the cumulative error. What happens if microtime() gets called in a tight loop? Oh, wait, I seem to recall that it has already been demonstrated that calling microtime in a tight loop screws things up! This is just more of the same, just with more bits to try to hide the problem. But it doesn't work if you have more processors, or faster processors. Adding more precision does NOT solve the problem. You would have to go to a 128 bit fractional quantity and that is just plain crazy. We are moving towards 10GHz in the next 10 years (probably less). With clusters one might need a unique timestamp and move to an offset counter mechanism (so each host is guarenteed completely unique timestamps) which is roughly 100GHz or 1THz virtual resolution. A 1/1E10 of cumulative error per call when a cpu may be making millions of calls is simply not acceptable. It is not a timing mechanism that will carry is forward. What happens if in the next 10 years platforms are phase-locked to each other? Think that's spacy? Gigabit ethernet already has to do it. I am not being totally wild here, I am being pragmatic. Error-prone representations are a bad base to work from. For kernel time keeping the only representation that is not prone to non-deterministic error creep is to store the time in the native counter format -- ticks at X frequency, or ticks at X*(constant) frequency. From there you can use a baseline cache conversion mechanism to convert it, with NO cumulative error, into some other format (if you need it in some other format). You wind up with a non-cumulative deterministic error no matter how often the routine is called, no matter what the frequency of the counter, etc etc etc. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:29:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by hub.freebsd.org (Postfix) with ESMTP id 37FB437B401 for ; Fri, 26 Oct 2001 15:29:33 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by marlborough.cnchost.com id SAA07928; Fri, 26 Oct 2001 18:29:30 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110262229.SAA07928@marlborough.cnchost.com> To: Poul-Henning Kamp Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Fri, 26 Oct 2001 21:46:51 +0200." <6790.1004125611@critter.freebsd.dk> Date: Fri, 26 Oct 2001 15:29:30 -0700 From: Bakul Shah 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 > The problem is that people tend to think of time as integers > instead of a floating point value. Precisely! So what I am suggesting is to count in the smallest unit that makes sense on a machine. Associate the number of zoptoseconds (or whatever) per tick and add that to your 96 bit kernel time. So adjtime() will change that zs/tick count. When you need to create a file timestamp, divide by appropriate 10^N number to map it to the correct unit. I just can't believe that this operation is so frequent so as to require a micro (1/2^20) optimization. The two are not very differen but there is a lot less of rounding error given the number of decimal clocks in use: 10/100/1000Mhz ethernet, SONET(where 8K frames are sent per second) and so on. Since they (1/2^64 versus a min. unit of zoptosecond) are so similar either is fine with me as far as the kernel time is concerned. I was really more interested in what gets stored in a file inode. For that I would very strongly argue for an integer multiple of a basic time unit of ns instead of timespec or timeval. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:34:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0C31E37B405 for ; Fri, 26 Oct 2001 15:34:06 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id IAA16269; Sat, 27 Oct 2001 08:33:57 +1000 Date: Sat, 27 Oct 2001 08:33:00 +1000 (EST) From: Bruce Evans X-X-Sender: To: Poul-Henning Kamp Cc: Peter Wemm , Subject: Re: 64 bit times revisited.. In-Reply-To: <23015.1004077694@critter.freebsd.dk> Message-ID: <20011027081803.N90305-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 26 Oct 2001, Poul-Henning Kamp wrote: > BUT, i would like to point out a problem in the other direction: > > We are now routinely talking about GHz+ CPUs, but struct timespec > can only do nanosecond resolution and arithmetic on timeval and > timespec sux badly. > > I would like for us to introduce a new format of timestamps: > > struct time$something { > time_t tx_sec; /* 64bit */ > uint_64_t tx_fsec; /* binary fraction of second */; > } > ... > Comments ? I happen to think that such micro-optimizations turn out to be much more trouble than they are worth. -- phk All final consumers of timestamps need decimal fractions, since syscall interfaces only pass timevals and timespecs. I suspect the above change won't make much difference to the amount of timefoo arithmetic, because most of it is for final consumers. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 15:47:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id BE05D37B401 for ; Fri, 26 Oct 2001 15:47:27 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 1605614C40; Sat, 27 Oct 2001 00:47:26 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bakul Shah Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110262229.SAA07928@marlborough.cnchost.com> From: Dag-Erling Smorgrav Date: 27 Oct 2001 00:47:25 +0200 In-Reply-To: <200110262229.SAA07928@marlborough.cnchost.com> Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Bakul Shah writes: > > The problem is that people tend to think of time as integers > > instead of a floating point value. > Precisely! So what I am suggesting is to count in the > smallest unit that makes sense on a machine. Associate the > number of zoptoseconds (or whatever) per tick and add that to > your 96 bit kernel time. You are all morons. It is painfully obvious we cannot make do with anything less than flobbosecond resolution, or we will seriously lose when we transition to 7-dimensional computation lattices and find that quadron fluctuations in the quantum phase-shift matrix is affecting make(1)s ability to correctly determine whether Richard Stallman is, in fact, Jesus reincarnate. Are we done with the bikeshed yet? Let's have those 64-bit time_ts now, please, and a coffee to go. Black, please, with two lumps. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 16: 1:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 1100037B403 for ; Fri, 26 Oct 2001 16:01:44 -0700 (PDT) Received: from hades.hell.gr (patr530-a204.otenet.gr [212.205.215.204]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f9QN1cL07121; Sat, 27 Oct 2001 02:01:38 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f9QGTYo16858; Fri, 26 Oct 2001 19:29:34 +0300 (EEST) (envelope-from charon@labs.gr) Date: Fri, 26 Oct 2001 19:29:34 +0300 From: Giorgos Keramidas To: Jeroen Ruigrok/Asmodai Cc: Lyndon Nerenberg , arch@FreeBSD.org Subject: Re: your mail Message-ID: <20011026192933.B16134@hades.hell.gr> References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> <20011026153313.C96876@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026153313.C96876@daemon.ninth-circle.org> User-Agent: Mutt/1.3.22.1i 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 On Fri, Oct 26, 2001 at 03:33:13PM +0200, Jeroen Ruigrok/Asmodai wrote: > >Based on this, what do you think about adding a NO_GNU_COMPLER_CMD_LINKS > >macro to make.conf? If set, if would prevent the linking of cc -> > >gcc and c++ -> g++, freeing up /usr/local/bin/g* for the site to > >decide? (And I'm not tied to that horribly long macro name, either.) > > I would sooner prefer the other way around. Have gcc and g++ and have a > knob to not create the gcc -> cc symlink. :) No please. I don't mind having both cc and gcc on my disks, but `cc' is the name of the system compiler. Since our system compiler is gcc, I'd expect both links to exist. Having a compiled named gcc is a GNU'ism that has stuck with us now, but having a compiler called cc is something that is part of what I've learned to call Unix. -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 16: 8:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id BC5E437B401 for ; Fri, 26 Oct 2001 16:08:53 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id QAA20978; Fri, 26 Oct 2001 16:08:02 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda20976; Fri Oct 26 16:07:46 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id f9QN7jK35266; Fri, 26 Oct 2001 16:07:45 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdB35247; Fri Oct 26 16:06:56 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id f9QN6t869229; Fri, 26 Oct 2001 16:06:55 -0700 (PDT) Message-Id: <200110262306.f9QN6t869229@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdH69193; Fri Oct 26 16:05:57 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Giorgos Keramidas Cc: Jeroen Ruigrok/Asmodai , Lyndon Nerenberg , arch@FreeBSD.ORG Subject: Re: your mail In-reply-to: Your message of "Fri, 26 Oct 2001 19:29:34 +0300." <20011026192933.B16134@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Oct 2001 16:05:57 -0700 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 In message <20011026192933.B16134@hades.hell.gr>, Giorgos Keramidas writes: > On Fri, Oct 26, 2001 at 03:33:13PM +0200, Jeroen Ruigrok/Asmodai wrote: > > >Based on this, what do you think about adding a NO_GNU_COMPLER_CMD_LINKS > > >macro to make.conf? If set, if would prevent the linking of cc -> > > >gcc and c++ -> g++, freeing up /usr/local/bin/g* for the site to > > >decide? (And I'm not tied to that horribly long macro name, either.) > > > > I would sooner prefer the other way around. Have gcc and g++ and have a > > knob to not create the gcc -> cc symlink. :) > > No please. > > I don't mind having both cc and gcc on my disks, but `cc' is the name > of the system compiler. Since our system compiler is gcc, I'd expect > both links to exist. Having a compiled named gcc is a GNU'ism that > has stuck with us now, but having a compiler called cc is something > that is part of what I've learned to call Unix. I agree. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 16:11:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 8E14E37B407 for ; Fri, 26 Oct 2001 16:11:29 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id f9QMop144984; Fri, 26 Oct 2001 23:50:51 +0100 (BST) (envelope-from nik) Date: Fri, 26 Oct 2001 23:50:51 +0100 From: Nik Clayton To: Bakul Shah Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026235051.A44793@clan.nothing-going-on.org> Reply-To: chat@freebsd.org References: <23015.1004077694@critter.freebsd.dk> <200110261748.NAA22627@rodney.cnchost.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110261748.NAA22627@rodney.cnchost.com>; from bakul@bitblocks.com on Fri, Oct 26, 2001 at 10:48:10AM -0700 Organization: FreeBSD Project 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 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Redirecting to -chat. On Fri, Oct 26, 2001 at 10:48:10AM -0700, Bakul Shah wrote: > IMHO there is not much point in using file timestamps of > resolutions less than 1 ns -- that is about 1 foot of travel > at the speed of light. Note that even a ns resolution will > cause problems on a multi-processor system where cpu nodes > are more than a foot or so apart=20 I always liked the fact that one of the Enterprise technical manuals (yeah, you want to make something of it?) noted that the computer core had a little warp field generator in it, so that the processors could communicate at FTL speeds. . . N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvZ6MsACgkQk6gHZCw343Ux8wCfdEDrrVzwP7dIGr/pewPPTLHo NzQAnjBakbBLbIQIECgNDDQchumEeQOW =AhvH -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 16:19: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 894A637B403 for ; Fri, 26 Oct 2001 16:19:03 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9QNIwL21649; Fri, 26 Oct 2001 16:18:58 -0700 (PDT) (envelope-from obrien) Date: Fri, 26 Oct 2001 16:18:58 -0700 From: "David O'Brien" To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026161858.A21629@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <20011026134453.B17758@dragon.nuxi.com> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Fri, Oct 26, 2001 at 05:51:01PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Fri, Oct 26, 2001 at 05:51:01PM -0400, Garrett Wollman wrote: > In article <20011026134453.B17758@dragon.nuxi.com> you write: > >64-bit for FreeBSD or 32-bit for FreeBSD. No 1/2's please. > > Are you prepared to do the work to ensure that `long' is the same > width on all FreeBSD architectures? If that is desired, I have patches from BDE to make gcc IP32L64.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 16:21: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 432EE37B401 for ; Fri, 26 Oct 2001 16:20:57 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QNKPS01466; Sat, 27 Oct 2001 01:20:25 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@FreeBSD.ORG Cc: Garrett Wollman Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 16:18:58 PDT." <20011026161858.A21629@dragon.nuxi.com> Date: Sat, 27 Oct 2001 01:20:25 +0200 Message-ID: <1464.1004138425@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <20011026161858.A21629@dragon.nuxi.com>, "David O'Brien" writes: >On Fri, Oct 26, 2001 at 05:51:01PM -0400, Garrett Wollman wrote: >> In article <20011026134453.B17758@dragon.nuxi.com> you write: >> >64-bit for FreeBSD or 32-bit for FreeBSD. No 1/2's please. >> >> Are you prepared to do the work to ensure that `long' is the same >> width on all FreeBSD architectures? > >If that is desired, I have patches from BDE to make gcc IP32L64.... I'm actually increasingly seeing the point in this idea... -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 16:21:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ajax.cnchost.com (ajax.cnchost.com [207.155.248.31]) by hub.freebsd.org (Postfix) with ESMTP id 5BBAD37B401 for ; Fri, 26 Oct 2001 16:21:25 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by ajax.cnchost.com id TAA14697; Fri, 26 Oct 2001 19:21:13 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110262321.TAA14697@ajax.cnchost.com> To: Dag-Erling Smorgrav Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "27 Oct 2001 00:47:25 +0200." Date: Fri, 26 Oct 2001 16:21:15 -0700 From: Bakul Shah 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 > You are all morons. It is painfully obvious we cannot make do with God Dag to you too! > anything less than flobbosecond resolution, or we will seriously lose > when we transition to 7-dimensional computation lattices and find that > quadron fluctuations in the quantum phase-shift matrix is affecting > make(1)s ability to correctly determine whether Richard Stallman is, > in fact, Jesus reincarnate. Are we done with the bikeshed yet? Let's Let me guess. If you haven't encountered a problem it can't be real, right? > have those 64-bit time_ts now, please, and a coffee to go. Black, > please, with two lumps. As I have already said in an earlier email: - leave time_t at 32 bit on all freebsd machines - add nstime64_t that has ns resolution and will work for 584 years. - add zstime128_t *if* people want higher resolution and to represent longer timespan I don't want to have to change a bunch of exiting programs just because someone decided change time_t to a 64 bit quantity. That is why I would really prefer a new typename for a 64 time type. For file timestamps nstime64_t seems adequate to me for reasons I gave before -- may be mtime/atime/utime type should not be called time_t either. What the kernel does to accurately represent time is kernel's business but that kernel time type should not be considered time_t. But I don't believe a single time type can fit all so I am for multiple time_t types. Also, this is problem is not peculiar to FreeBSD and I really hope you (core) guys try to come to some consensus with other OS groups. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 16:46:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0F77237B403 for ; Fri, 26 Oct 2001 16:46:32 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id AA43714C2E; Sat, 27 Oct 2001 01:46:29 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bakul Shah Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110262321.TAA14697@ajax.cnchost.com> From: Dag-Erling Smorgrav Date: 27 Oct 2001 01:46:29 +0200 In-Reply-To: <200110262321.TAA14697@ajax.cnchost.com> Message-ID: Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Bakul Shah writes: > I don't want to have to change a bunch of exiting programs > just because someone decided change time_t to a 64 bit > quantity. That is why I would really prefer a new typename > for a 64 time type. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no and no. I'm almost insulted that you (and others) seem to be arguing from the premise that us effwit FreeBSD committers are too stupid to realize we need to provide an upgrade path. Give us some effing credit. > For file timestamps nstime64_t seems adequate to me for reasons > I gave before -- may be mtime/atime/utime type should not be > called time_t either. Obviously. After all, nobody uses time_t for anything else that file timestamps - at least nobody we care about (or will care about in 2038), so there's no need for ctime(), difftime(), gmtime(), localtime(), mktime(), time(), timelocal() or timegm() to continue working as before. > Also, this is problem is not peculiar to FreeBSD and I really > hope you (core) guys try to come to some consensus with other > OS groups. Since you're so stuck up about standardization, go see POSIX or SUSv2 or the Austin spec and show me a single reference to "nstime64_t" in any one of those documents. I will not discuss this any further. It's too much like teaching pigs to sing. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 17: 0:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 64BFA37B401 for ; Fri, 26 Oct 2001 17:00:35 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R0DCv05573; Fri, 26 Oct 2001 17:13:13 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270013.f9R0DCv05573@mass.dis.org> To: Dag-Erling Smorgrav Cc: Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Dag-Erling Smorgrav of "27 Oct 2001 01:46:29 +0200." Date: Fri, 26 Oct 2001 17:13:12 -0700 From: Mike Smith 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 > Since you're so stuck up about standardization, go see POSIX or SUSv2 > or the Austin spec and show me a single reference to "nstime64_t" in > any one of those documents. > > I will not discuss this any further. It's too much like teaching pigs > to sing. Much of this discussion leans this way. Just think about all this for a second, folks. We have about twenty years before this is a real problem. We have about twenty years worth of real work that needs to be done. So why don't we just put the whole, stupid time_t issue back at the bottom of the list, and get on with any of the hundreds of much more important issues that need to be dealt with, ok? And before anyone gets their knickers in a knot, remember this; all of the system time values (time_t, timeval, timespec) are meant to represent possible values of "now". Until "now" starts to blow them out, we have much bigger fish to fry. = Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 17:38:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 42CA837B406; Fri, 26 Oct 2001 17:38:31 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R0cT442082; Fri, 26 Oct 2001 17:38:29 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 17:38:29 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270038.f9R0cT442082@apollo.backplane.com> To: Mike Smith Cc: Dag-Erling Smorgrav , Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110270013.f9R0DCv05573@mass.dis.org> 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 :Much of this discussion leans this way. : :Just think about all this for a second, folks. : :We have about twenty years before this is a real problem. : :We have about twenty years worth of real work that needs to be done. : :So why don't we just put the whole, stupid time_t issue back at the :bottom of the list, and get on with any of the hundreds of much more :important issues that need to be dealt with, ok? : :And before anyone gets their knickers in a knot, remember this; all of :the system time values (time_t, timeval, timespec) are meant to :represent possible values of "now". Until "now" starts to blow them :out, we have much bigger fish to fry. : : = Mike Actually not quite true. We had to spend two weeks writing date/time routines because the standard UNIX time_t routines couldn't go past 2038. The time_t limitations are creating problems *NOW*. It messes up simulations, forward looking views, contracts that start now and end after 2038, astronomical programs, etc etc etc. Some of the turnkey software I wrote 20 years ago is *still* *being* *used* today. We don't have 36 years to implement this, it's a problem that needs to be solved now. time_t's problem is similar to off_t's problem... it's best to get the pain over with *NOW* rather then later. Then it's there when you need it. - It seems we have enough of a concensus for someone to actually start doing this in -current. I went through the syscalls and these are the ones we would have to roll to maintain basic binary compatibility. stat (stat) fstat (stat) lstat (stat) fhstat (stat) select (timeval) gettimeofday (timeval) settimeofday (timeval) utimes (timeval) adjtime (timeval) futimes (timeval) lutimes (timeval) clock_gettime (timespec) clock_settime (timespec) clock_getres (timespec) nanosleep (timespec) aio_suspend (timespec) thr_sleep (timespec) sched_rr_get_interval (timespec) aio_waitcomplete (timespec) kevent (timespec) ntp_adjtime (timex) Is anyone game for this project? I could probably do the all the necessary kernel work in a day but we would need a general audit of the rest of the source tree to cleanup everything else and make sure the time conversion routines still work. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 17:41:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9976A37B406 for ; Fri, 26 Oct 2001 17:41:43 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R0fci42111; Fri, 26 Oct 2001 17:41:38 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 17:41:38 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270041.f9R0fci42111@apollo.backplane.com> To: "David O'Brien" Cc: Garrett Wollman , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <20011026134453.B17758@dragon.nuxi.com> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> <20011026161858.A21629@dragon.nuxi.com> 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 : :On Fri, Oct 26, 2001 at 05:51:01PM -0400, Garrett Wollman wrote: :> In article <20011026134453.B17758@dragon.nuxi.com> you write: :> >64-bit for FreeBSD or 32-bit for FreeBSD. No 1/2's please. :> :> Are you prepared to do the work to ensure that `long' is the same :> width on all FreeBSD architectures? : :If that is desired, I have patches from BDE to make gcc IP32L64.... I don't think this could be done without major major syscall compatibility work. A large number of routines take or return 'long' arguments. Binary compatibility would go poof. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 17:45: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9FF0A37B403; Fri, 26 Oct 2001 17:44:59 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id D5ECB14C2E; Sat, 27 Oct 2001 02:44:57 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Matthew Dillon Cc: Mike Smith , Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110270013.f9R0DCv05573@mass.dis.org> <200110270038.f9R0cT442082@apollo.backplane.com> From: Dag-Erling Smorgrav Date: 27 Oct 2001 02:44:57 +0200 In-Reply-To: <200110270038.f9R0cT442082@apollo.backplane.com> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Matthew Dillon writes: > Is anyone game for this project? I'd volunteer, but I have too many of my own patches to worry about right now. How about mid-November, after BSDCon Europe? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 17:57:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id AD25A37B401 for ; Fri, 26 Oct 2001 17:57:10 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R19uv06023; Fri, 26 Oct 2001 18:09:56 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270109.f9R19uv06023@mass.dis.org> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Matthew Dillon of "Fri, 26 Oct 2001 17:38:29 PDT." <200110270038.f9R0cT442082@apollo.backplane.com> Date: Fri, 26 Oct 2001 18:09:56 -0700 From: Mike Smith 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 > :And before anyone gets their knickers in a knot, remember this; all of > :the system time values (time_t, timeval, timespec) are meant to > :represent possible values of "now". Until "now" starts to blow them > :out, we have much bigger fish to fry. > : > Actually not quite true. We had to spend two weeks writing date/time > routines because the standard UNIX time_t routines couldn't go past > 2038. The time_t limitations are creating problems *NOW*. It messes > up simulations, forward looking views, contracts that start now and > end after 2038, astronomical programs, etc etc etc. I'll say it again, then. These programs should *not* be trying to use these functions. These functions are meant for manipulating time_t, which is a representation of "now". You should be using appropriate types and functions for your application. The system functions you are trying to use are not appropriate, and screwing up the system and all of the applications that use these functions just for your own selfish purposes is *not* appropriate. > Some of the turnkey > software I wrote 20 years ago is *still* *being* *used* today. And I bet you didn't spend enormous amounts of effort at the time trying to change the world so that your programs would still be working today, either. > We don't have 36 years to implement this, it's a problem that needs to > be solved now. I've already refuted this claim. > time_t's problem is similar to off_t's problem... it's best to get the > pain over with *NOW* rather then later. Then it's there when you need it. This is unsubstantiated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 17:57:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7DFAC37B401; Fri, 26 Oct 2001 17:57:18 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R0vG642220; Fri, 26 Oct 2001 17:57:16 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 17:57:16 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270057.f9R0vG642220@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: Mike Smith , Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110270013.f9R0DCv05573@mass.dis.org> <200110270038.f9R0cT442082@apollo.backplane.com> 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 : :Matthew Dillon writes: :> Is anyone game for this project? : :I'd volunteer, but I have too many of my own patches to worry about :right now. How about mid-November, after BSDCon Europe? : :DES :-- :Dag-Erling Smorgrav - des@ofug.org With the vnode and sync scaleability stuff *almost* out of the way I've started working on the Giant lock unwinding stuff, so I don't have time this moment either, but I would certainly have time available mid-november to help out! The project could be done and stabilized in a week with three or more people helping out. There is good functional separation: * type changes (stat, timespec, timeval, timex, time_t) * syscall number rolls & compatibility code (sorry BSDI, it's more then 10) * kernel side audit to handle new time_t & structures * libc audit - all time related functions * userland audit to handle new time_t & structures I think everyone has agreed on time_t going to 64 bits, and of course it must be seconds. We have to decide in regards to timeval, stat, and timespec. It looks like we may not have to mess with timex, which is good. machine/ansi.h:#define _BSD_TIME_T_ long /* time()... */ struct timeval { long tv_sec; /* seconds */ long tv_usec; /* and microseconds */ }; struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* and nanoseconds */ }; struct stat { ... #ifndef _POSIX_SOURCE struct timespec st_atimespec; /* time of last access */ struct timespec st_mtimespec; /* time of last data modification */ struct timespec st_ctimespec; /* time of last file status change */ #else time_t st_atime; /* time of last access */ long st_atimensec; /* nsec of last access */ time_t st_mtime; /* time of last data modification */ long st_mtimensec; /* nsec of last data modification */ time_t st_ctime; /* time of last file status change */ long st_ctimensec; /* nsec of last file status change */ #endif }; (there might be other in-kernel structures that we have to mess with) Obviously tv_sec in timeval has to change from long to time_t, and time_t has to change from long to int64_t. The stat structure gets a bit larger... presumably we have to keep the 'long ... nsec' elements in both the timespec and stat structure to maintain compatibility. Anything else? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18: 2:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E518737B403; Fri, 26 Oct 2001 18:02:28 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R12SO42251; Fri, 26 Oct 2001 18:02:28 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 18:02:28 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270102.f9R12SO42251@apollo.backplane.com> To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110270109.f9R19uv06023@mass.dis.org> 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 : :> :And before anyone gets their knickers in a knot, remember this; all of :> :the system time values (time_t, timeval, timespec) are meant to :> :represent possible values of "now". Until "now" starts to blow them :> :out, we have much bigger fish to fry. :> : :> Actually not quite true. We had to spend two weeks writing date/time :> routines because the standard UNIX time_t routines couldn't go past :> 2038. The time_t limitations are creating problems *NOW*. It messes :> up simulations, forward looking views, contracts that start now and :> end after 2038, astronomical programs, etc etc etc. : :I'll say it again, then. : :These programs should *not* be trying to use these functions. These functions :are meant for manipulating time_t, which is a representation of "now". Who says? Programs have used these functions to manipulate the concept of time ever since the functions first came into being. Are you suggesting that every single person who writes a program that manipulates time that may not be 'now' must go and write his own library to support that function? Sorry, did that already... didn't like it a bit. We have a wonderful set of time-related library functions that take into account daylight savings time and all sorts of other goodies and I want to be able to use them. Your position makes no sense, Mike. We have to deal with programs that are already written as well as developers expectations. Your expectations seem far out in left field to me. time_t is a representation of time, not a representation of time 'now'. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18: 6: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 320D037B401; Fri, 26 Oct 2001 18:06:03 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 0236314C2E; Sat, 27 Oct 2001 03:06:01 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Mike Smith Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110270109.f9R19uv06023@mass.dis.org> From: Dag-Erling Smorgrav Date: 27 Oct 2001 03:06:00 +0200 In-Reply-To: <200110270109.f9R19uv06023@mass.dis.org> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Mike Smith writes: > These programs should *not* be trying to use these functions. These > functions are meant for manipulating time_t, which is a > representation of "now". Mike, we can't fix everybody else's broken software. What we *can* do is fix *ours* so it plays nice with theirs. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:17:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id E6F9E37B401 for ; Fri, 26 Oct 2001 18:17:08 -0700 (PDT) Received: (qmail 21462 invoked from network); 27 Oct 2001 01:17:08 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 01:17:08 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200110270057.f9R0vG642220@apollo.backplane.com> Date: Fri, 26 Oct 2001 18:17:05 -0700 (PDT) From: John Baldwin To: Matthew Dillon Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG, Peter Wemm , Poul-Henning Kamp , Bakul Shah , Mike Smith , Dag-Erling Smorgrav 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 On 27-Oct-01 Matthew Dillon wrote: > >: >:Matthew Dillon writes: >:> Is anyone game for this project? >: >:I'd volunteer, but I have too many of my own patches to worry about >:right now. How about mid-November, after BSDCon Europe? >: >:DES >:-- >:Dag-Erling Smorgrav - des@ofug.org > > With the vnode and sync scaleability stuff *almost* out of the way I've > started working on the Giant lock unwinding stuff, so I don't have time > this moment either, but I would certainly have time available > mid-november to help out! > > The project could be done and stabilized in a week with three or more > people helping out. There is good functional separation: > > > * type changes (stat, timespec, timeval, timex, time_t) > * syscall number rolls & compatibility code (sorry BSDI, it's more then > 10) > * kernel side audit to handle new time_t & structures > * libc audit - all time related functions > * userland audit to handle new time_t & structures > > > I think everyone has agreed on time_t going to 64 bits, and of course > it must be seconds. We have to decide in regards to timeval, stat, and > timespec. It looks like we may not have to mess with timex, which is > good. You did read the e-mail from Garrett where either SUS or POSIX one requires time_t to fit in a long? I.e. sizeof(time_t) <= sizeof(long). This means that if you bump time_t to 64 on i386, you have to bump long to 64, which is decidely something many people don't want to do. I would suggest if you insist on working on this, you first convert time_t to a long so that platforms with 64-bit longs will have a 64-bit time_t, and then once you've cleaned up the messes that makes, you will still have time to decide if you want ppc and i386 to go form ILP32 to IP32L64 (or however you specify that) which will probably involve backwards compatible syscalls, etc. One step a time. You don't have to do it all at once, and after doing the first step, you may find that that is enough. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:21: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id DE5C337B403 for ; Fri, 26 Oct 2001 18:21:03 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R1Xnv06295; Fri, 26 Oct 2001 18:33:49 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270133.f9R1Xnv06295@mass.dis.org> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Matthew Dillon of "Fri, 26 Oct 2001 18:02:28 PDT." <200110270102.f9R12SO42251@apollo.backplane.com> Date: Fri, 26 Oct 2001 18:33:49 -0700 From: Mike Smith 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 > :These programs should *not* be trying to use these functions. These functions > :are meant for manipulating time_t, which is a representation of "now". > > Who says? This is the definition of time_t. > Programs have used these functions to manipulate the concept > of time ever since the functions first came into being. And in many cases, that's perfectly appropriate, and time_t is more than adequate. However the examples you're citing as justification for this change are applications where time_t and friends just aren't appropriate. > Are you > suggesting that every single person who writes a program that manipulates > time that may not be 'now' must go and write his own library to support > that function? No. There are many time manipulation toolsets around customised for timescales other than reasonable values for "now". Pick one that suits your application and use it. Just don't go screwing up the time_t model to suit your own needs. > Your position makes no sense, Mike. We have to deal with programs that > are already written as well as developers expectations. Your expectations > seem far out in left field to me. time_t is a representation of time, > not a representation of time 'now'. That's just not correct. The concept of seconds post epoch is very definitely intended as a mechanism for representing a reasonable value of "now". If you're going to go and implement an incompatible mechanism for keeping track of time, at least have the good grace and civility to do so without ruining what is already a perfectly adequate means of representing the current system time. If you do a good enough job, it will probably become the new default, and over the next twenty years or so everyone will migrate to it. In the meantime, please do us all the favour of *not* screwing up the current way things are done. time_t will continue to be perfectly adequate for what it was designed for for another thirty years; imposing the sorts of changes you're talking about at this point in time just doesn't make any sort of good sense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:23:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id A524F37B406 for ; Fri, 26 Oct 2001 18:23:26 -0700 (PDT) Received: (qmail 84227 invoked from network); 27 Oct 2001 01:23:25 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 01:23:25 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 26 Oct 2001 18:23:23 -0700 (PDT) From: John Baldwin To: John Baldwin Subject: Re: 64 bit times revisited.. Cc: Dag-Erling Smorgrav , Mike Smith , Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG, Matthew Dillon 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 On 27-Oct-01 John Baldwin wrote: > > On 27-Oct-01 Matthew Dillon wrote: >> >>: >>:Matthew Dillon writes: >>:> Is anyone game for this project? >>: >>:I'd volunteer, but I have too many of my own patches to worry about >>:right now. How about mid-November, after BSDCon Europe? >>: >>:DES >>:-- >>:Dag-Erling Smorgrav - des@ofug.org >> >> With the vnode and sync scaleability stuff *almost* out of the way I've >> started working on the Giant lock unwinding stuff, so I don't have time >> this moment either, but I would certainly have time available >> mid-november to help out! >> >> The project could be done and stabilized in a week with three or more >> people helping out. There is good functional separation: >> >> >> * type changes (stat, timespec, timeval, timex, time_t) >> * syscall number rolls & compatibility code (sorry BSDI, it's more then >> 10) >> * kernel side audit to handle new time_t & structures >> * libc audit - all time related functions >> * userland audit to handle new time_t & structures >> >> >> I think everyone has agreed on time_t going to 64 bits, and of course >> it must be seconds. We have to decide in regards to timeval, stat, and >> timespec. It looks like we may not have to mess with timex, which is >> good. > > You did read the e-mail from Garrett where either SUS or POSIX one requires > time_t to fit in a long? I.e. sizeof(time_t) <= sizeof(long). This means > that if you bump time_t to 64 on i386, you have to bump long to 64, which is > decidely something many people don't want to do. I would suggest if you > insist > on working on this, you first convert time_t to a long so that platforms with > 64-bit longs will have a 64-bit time_t, and then once you've cleaned up the > messes that makes, you will still have time to decide if you want ppc and > i386 > to go form ILP32 to IP32L64 (or however you specify that) which will probably > involve backwards compatible syscalls, etc. One step a time. You don't have > to do it all at once, and after doing the first step, you may find that that > is > enough. My bad. C90 requires that time_t fit into a long according to Garrett. POSIX requires it to be either an integer or floating point with the fractional part zero according to his mail as well. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:24:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 281A937B401 for ; Fri, 26 Oct 2001 18:24:47 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R1bVv06321; Fri, 26 Oct 2001 18:37:31 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270137.f9R1bVv06321@mass.dis.org> To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Dag-Erling Smorgrav of "27 Oct 2001 03:06:00 +0200." Date: Fri, 26 Oct 2001 18:37:31 -0700 From: Mike Smith 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 > Mike Smith writes: > > These programs should *not* be trying to use these functions. These > > functions are meant for manipulating time_t, which is a > > representation of "now". > > Mike, we can't fix everybody else's broken software. What we *can* do > is fix *ours* so it plays nice with theirs. Our software doesn't need fixing. It works just fine, and just as it always has right now. This "fixing" you're talking about will introduce subtle and egregious problems in all manner of situations, and the amount of grief that it will cause will far outweigh any of the putative "benefits" that have been suggested so far. If there is a shift in the time_t paradigm, it's going to need to be driven by the industry at large, and it will need to be supported by wider consensus than a small frothing cabal such as currently stands behind this set of proposals. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:50:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 0920E37B923 for ; Fri, 26 Oct 2001 18:47:09 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id E5B134CE03; Fri, 26 Oct 2001 21:46:54 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA27139; Fri, 26 Oct 2001 21:46:53 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA16181; Fri, 26 Oct 2001 18:46:53 -0700 (PDT) Message-Id: <200110270146.SAA16181@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: wollman@khavrinen.lcs.mit.edu Subject: Re: 64 bit times revisited.. Cc: asmodai@wxs.nl, arch@freebsd.org References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> <200110262209.f9QM9on75561@khavrinen.lcs.mit.edu> Date: Fri, 26 Oct 2001 18:46:52 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b 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 >If we care about compatibility with ISO 9899:1990 (Standard C 1990 >edition), time_t is restricted to be no longer than `long'. I'll admit to only having subsets of C90, but both the subset of C90 that I have access to (in P.J. Plauger's "The Standard C Library") and the working draft of WG14/N794 J11/97-158 that I have from 1997 (which I think was a snapshot of what became C99) simply say (in section 7.16.1): The types declared [in ] are ... clock_t and time_t which are arithmetic types capable of representing times. Are you saying that C90 has an explicit requirement that time_t can't be longer than 'long', or simply that C90 didn't have any types longer than 'long'? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:51: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 113CD37B9AA; Fri, 26 Oct 2001 18:47:50 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id C2C8314C2E; Sat, 27 Oct 2001 03:47:33 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: John Baldwin Cc: Mike Smith , Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG, Matthew Dillon Subject: Re: 64 bit times revisited.. References: From: Dag-Erling Smorgrav Date: 27 Oct 2001 03:47:33 +0200 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 John Baldwin writes: > My bad. C90 requires that time_t fit into a long according to > Garrett. Maybe it does. Maybe it doesn't. Chapter and verse, please. All I have is the final draft of C99, and all it says about the width of time_t is that it is an arithmetic type "capable of representing times" (7.23.1). There is no mention at all of the word "long" in section 7.23. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:51: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id E2D7D37BAEA; Fri, 26 Oct 2001 18:49:27 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9R1qvi02323; Fri, 26 Oct 2001 21:52:57 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Oct 2001 21:52:56 -0400 From: Mike Barcroft To: Mike Smith Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026215256.A2283@coffee.q9media.com> References: <200110270109.f9R19uv06023@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110270109.f9R19uv06023@mass.dis.org>; from msmith@FreeBSD.ORG on Fri, Oct 26, 2001 at 06:09:56PM -0700 Organization: The FreeBSD Project 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 Mike Smith writes: > I'll say it again, then. > > These programs should *not* be trying to use these functions. These functions > are meant for manipulating time_t, which is a representation of "now". C99 defines clock_t and time_t as "arithmetic types capable of representing times". I can't find any reference in POSIX or C99 that time_t or its associated functions only deal with time as "now". Could you please reference the source of this information. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:51: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1B9D137BAFF; Fri, 26 Oct 2001 18:49:33 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 54A5514C40; Sat, 27 Oct 2001 03:49:16 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Mike Smith Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110270133.f9R1Xnv06295@mass.dis.org> From: Dag-Erling Smorgrav Date: 27 Oct 2001 03:49:15 +0200 In-Reply-To: <200110270133.f9R1Xnv06295@mass.dis.org> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Mike Smith writes: > > :These programs should *not* be trying to use these functions. These functions > > :are meant for manipulating time_t, which is a representation of "now". > > > > Who says? > This is the definition of time_t. Chapter and verse, please. Not just a repetition of what somebody else says may or may not be in C90. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:51:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 5095B37B409; Fri, 26 Oct 2001 18:51:34 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9R1pYM46215; Fri, 26 Oct 2001 18:51:34 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E4539380A; Fri, 26 Oct 2001 18:51:33 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mike Smith Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <200110270137.f9R1bVv06321@mass.dis.org> Date: Fri, 26 Oct 2001 18:51:33 -0700 From: Peter Wemm Message-Id: <20011027015133.E4539380A@overcee.netplex.com.au> 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 Mike Smith wrote: > If there is a shift in the time_t paradigm, it's going to need to be > driven by the industry at large, and it will need to be supported by > wider consensus than a small frothing cabal such as currently stands > behind this set of proposals. Does "Linux" represent a large enough portion of the Unix industry? Its 64 bit platforms have 64 bit time_t (long) and their 32 bit platforms have 32 bit time_t (long). We have new 64 bit platforms coming online as we speak. It would be a terrible shame to waste the opportunity to resolve it. Unlike the others in the thread, I see little benefit but lots of pain, in changing time_t on i386. I doubt i386 32 bit apps will be around in 20 years. If it lives on, it will be something like x86-64 or intel's spin on that. It too will have 64 bit "long" and we can use a 64 bit time_t there. I dont see sufficient reason to inflict this pain on i386 in the name of having the same size time_t. Having the same type (long) - yes, but using a quad_t is just expensive overkill. I wish I hadn't even brought up the possibility of changing i386. I didn't make it clear enough how much I hated the idea of it. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:52:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 0344837B401; Fri, 26 Oct 2001 18:52:40 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9R1ubk02360; Fri, 26 Oct 2001 21:56:37 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Oct 2001 21:56:37 -0400 From: Mike Barcroft To: John Baldwin Cc: Garrett Wollman , Dag-Erling Smorgrav , Mike Smith , Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG, Matthew Dillon Subject: Re: 64 bit times revisited.. Message-ID: <20011026215637.B2283@coffee.q9media.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from jhb@FreeBSD.ORG on Fri, Oct 26, 2001 at 06:23:23PM -0700 Organization: The FreeBSD Project 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 John Baldwin writes: > My bad. C90 requires that time_t fit into a long according to Garrett. POSIX > requires it to be either an integer or floating point with the fractional part > zero according to his mail as well. It appears they've corrected this in C99. Garrett, can you confirm this? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 18:52:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id BF36B37B401 for ; Fri, 26 Oct 2001 18:52:42 -0700 (PDT) Received: (qmail 27209 invoked from network); 27 Oct 2001 01:52:42 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 01:52:42 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 26 Oct 2001 18:52:37 -0700 (PDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: 64 bit times revisited.. Cc: Matthew Dillon , arch@FreeBSD.ORG, Peter Wemm , Poul-Henning Kamp , Bakul Shah , Mike Smith 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 On 27-Oct-01 Dag-Erling Smorgrav wrote: > John Baldwin writes: >> My bad. C90 requires that time_t fit into a long according to >> Garrett. > > Maybe it does. Maybe it doesn't. Chapter and verse, please. > > All I have is the final draft of C99, and all it says about the width > of time_t is that it is an arithmetic type "capable of representing > times" (7.23.1). There is no mention at all of the word "long" in > section 7.23. I was merely bringing up teh point snice most everyone else seemed to just ignore it. There are several people on here with copies of C90, I'm sure one can pop up with what it says about time_t. > DES > -- > Dag-Erling Smorgrav - des@ofug.org -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19: 1:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id AB0C437B405; Fri, 26 Oct 2001 19:01:42 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R2ESv06734; Fri, 26 Oct 2001 19:14:28 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270214.f9R2ESv06734@mass.dis.org> To: Mike Barcroft Cc: Mike Smith , Matthew Dillon , arch@FreeBSD.ORG, msmith@mass.dis.org Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Mike Barcroft of "Fri, 26 Oct 2001 21:52:56 EDT." <20011026215256.A2283@coffee.q9media.com> Date: Fri, 26 Oct 2001 19:14:28 -0700 From: Mike Smith 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 > Mike Smith writes: > > I'll say it again, then. > > > > These programs should *not* be trying to use these functions. These functions > > are meant for manipulating time_t, which is a representation of "now". > > C99 defines clock_t and time_t as "arithmetic types capable of > representing times". I can't find any reference in POSIX or C99 that > time_t or its associated functions only deal with time as "now". > Could you please reference the source of this information. You could try to be more subtle. However, I'll say it yet again. time_t, and the seconds-from-epoch model represent system time. This is just how it works. What Matt is in a tizzy about is that he's just realised that "system time" isn't necessarily all-encompassing, and that he needs something better. The mistake that's being made is in assuming that these functions should be gratuitously changed to suit this sort of application, rather than finding and using tools more suitable to the application in the first place. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:10:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id AA12637B405 for ; Fri, 26 Oct 2001 19:10:10 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R2Mtv06821; Fri, 26 Oct 2001 19:22:55 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270222.f9R2Mtv06821@mass.dis.org> To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Dag-Erling Smorgrav of "27 Oct 2001 03:49:15 +0200." Date: Fri, 26 Oct 2001 19:22:55 -0700 From: Mike Smith 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 > Mike Smith writes: > > > :These programs should *not* be trying to use these functions. These functions > > > :are meant for manipulating time_t, which is a representation of "now". > > > > > > Who says? > > This is the definition of time_t. > > Chapter and verse, please. Not just a repetition of what somebody > else says may or may not be in C90. I'm not pointing to any standard; I'm pointing to the fundamental assumptions that underly the use and implementation of the seconds-from-epoch model. You're off the topic here though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:12: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id DD2C637B405 for ; Fri, 26 Oct 2001 19:12:00 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R2Ojv06850; Fri, 26 Oct 2001 19:24:46 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270224.f9R2Ojv06850@mass.dis.org> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Peter Wemm of "Fri, 26 Oct 2001 18:51:33 PDT." <20011027015133.E4539380A@overcee.netplex.com.au> Date: Fri, 26 Oct 2001 19:24:45 -0700 From: Mike Smith 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 > Mike Smith wrote: > > > If there is a shift in the time_t paradigm, it's going to need to be > > driven by the industry at large, and it will need to be supported by > > wider consensus than a small frothing cabal such as currently stands > > behind this set of proposals. > > Does "Linux" represent a large enough portion of the Unix industry? > Its 64 bit platforms have 64 bit time_t (long) and their 32 bit platforms > have 32 bit time_t (long). If there's a rift in the industry, then siding with Linux is probably a safe move, given that a sanity check on their activities doesn't make us barf. 8) > I wish I hadn't even brought up the possibility of changing i386. I didn't > make it clear enough how much I hated the idea of it. I'm sure we can arrange for you to suffer for it later. 8) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:17:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id E577437B403 for ; Fri, 26 Oct 2001 19:17:08 -0700 (PDT) Received: (qmail 63051 invoked by uid 1000); 27 Oct 2001 02:17:08 -0000 Date: Fri, 26 Oct 2001 22:17:08 -0400 From: Joe Abley To: Mike Barcroft Cc: "Bruce A. Mah" , Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011026221708.F59676@buffoon.automagic.org> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> <20011026131209.B355@coffee.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026131209.B355@coffee.q9media.com> User-Agent: Mutt/1.3.22.1i 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 On Fri, Oct 26, 2001 at 01:12:10PM -0400, Mike Barcroft wrote: > Bruce A. Mah writes: > > Rather than us guessing at the meaning (which I feel *is* rather > > ambiguous), would it make sense for someone to request clarification > > from some suitable representative of Lucent, telling them exactly what > > the plans are and asking if they're compatible with the license? The > > Web page has a pointer to Brian Kernighan...I'm pretty sure he'd know > > the answer. :-) > > Since you came up with the idea, do you want to contact Lucent and > report back to the list when you find an answer? There is one more thing that is worth checking -- there are two of my awk scripts involved in building bits of boot loader: sys/boot/common/merge_help.awk sys/boot/ficl/softwords/softcore.awk The first script contains [[:graph:]] and [[:print:]] patterns, and the second one uses [[:space:]]. There are function definitions used in softcore.awk, too. These are not show-stoppers, but if the decision is made to change the build/system awk, someone might like to ping me so I can make sure these scripts still work. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:18:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 6DD7E37B401 for ; Fri, 26 Oct 2001 19:18:54 -0700 (PDT) Received: from dialup-209.245.143.103.dial1.sanjose1.level3.net ([209.245.143.103] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xJ3V-0007VQ-00; Fri, 26 Oct 2001 19:18:38 -0700 Message-ID: <3BDA19B1.F26651DC@mindspring.com> Date: Fri, 26 Oct 2001 19:19:29 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Julian Elischer , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110261707.f9QH7F437553@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Matthew Dillon wrote: > This is a bad idea. There's no point, because processors are only > getting faster. Even nanosecond resolution isn't enough and we have > other issues simply due to new computing methodologies such as parallel > and distributed processing. 'make's issues aren't enough to justify > complexifying atime/ctime/mtime. The "make" issues are real; they're just not solvable without some careful thought. The easiest fix would be to calculate the graph, and then act on it on the assumption that equal times are in order, and that a generation target for which an action was required was in fact generated, despite the timestamp being equal. The other suggestion I made earlier, ensuring monotonically increasing timestamps, works as well, but causes real problems at seconds of resolution, instead of smaller intervals of measure -- as Poul pointed out. A better way might be a file creation monotonicity stamp, on a per file, per directory basis, but that remains to be seen. We're all screwed without something like that, once quantum computing comes online, anyway. 8-). > The larger problem that we need to solve are the ridiculous calendar > limitations. We have to solve the problem *permanently* this time, > we have to solve them obviously, with as little additional complexity > as possible. We have to have a solution that is *uniform* across the > system, and a full 64 bit 1-second resolution field will do that. > We should not be screwing around with other clutter. I have this vision of an SF novel, where human civilization is destroyed 29 billion years from now because of 64 bit seconds, and the fact that all computer programming is done by machines instead of by humans... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:24:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id 09FD337B407 for ; Fri, 26 Oct 2001 19:24:26 -0700 (PDT) Received: (qmail 63145 invoked by uid 1000); 27 Oct 2001 02:24:24 -0000 Date: Fri, 26 Oct 2001 22:24:24 -0400 From: Joe Abley To: Mike Barcroft Cc: "Bruce A. Mah" , Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011026222423.H59676@buffoon.automagic.org> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> <20011026131209.B355@coffee.q9media.com> <20011026221708.F59676@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026221708.F59676@buffoon.automagic.org> User-Agent: Mutt/1.3.22.1i 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 On Fri, Oct 26, 2001 at 10:17:08PM -0400, Joe Abley wrote: > There are function definitions > the second one uses [[:space:]]. There are function definitions > used in softcore.awk, too. Ah, I just looked, and I see functions are supported in the awk in question (assuming ports/lang/nawk is that awk). I will remove the outstanding gawkisms in these scripts now anyway and submit a PR. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:27:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id E518A37B401 for ; Fri, 26 Oct 2001 19:27:07 -0700 (PDT) Received: from dialup-209.245.143.103.dial1.sanjose1.level3.net ([209.245.143.103] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xJBf-000698-00; Fri, 26 Oct 2001 19:27:03 -0700 Message-ID: <3BDA1BAC.6DD81122@mindspring.com> Date: Fri, 26 Oct 2001 19:27:56 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai Cc: Poul-Henning Kamp , Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <2912.1004113233@critter.freebsd.dk> <3BD993A6.E6B12512@mindspring.com> <20011026214703.K96876@daemon.ninth-circle.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Jeroen Ruigrok/Asmodai wrote: > > -On [20011026 18:49], Terry Lambert (tlambert2@mindspring.com) wrote: > >According to you, that won't bite anyone for 10 years. > > I have heard arguments like this before. > > ``The solution is temporary.'' > ``But we will replace this with the correct stuff in a few > days/weeks/months/years.'' > > 10 years passes quickly has been my experience and I rather have a good > solution than one which fills the gap for 10 years now and that we get > this entire revisitation 10 years from now. > > But that's my personal belief and observations. You need to read the entire discussion. He was attacking a solution that was "only good for 10 years", in favor of one that was "only good for 37 years". I was being ironic. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:27:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id DA2B837B405 for ; Fri, 26 Oct 2001 19:27:29 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R2eGv07017 for ; Fri, 26 Oct 2001 19:40:16 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270240.f9R2eGv07017@mass.dis.org> To: arch@freebsd.org Subject: time_t not to change size on x86 Date: Fri, 26 Oct 2001 19:40:16 -0700 From: Mike Smith 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 Just to clarify, based on Peter's last mail. The proposal is not to change the size of time_t on x86, merely to select a suitable size on new platforms so that we migrate in a suitable fashion. This is fine, and a sensible idea. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:33:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id DB15D37B405; Fri, 26 Oct 2001 19:33:54 -0700 (PDT) Received: from dialup-209.245.143.103.dial1.sanjose1.level3.net ([209.245.143.103] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xJIG-0003hu-00; Fri, 26 Oct 2001 19:33:52 -0700 Message-ID: <3BDA1D45.B4D46F0B@mindspring.com> Date: Fri, 26 Oct 2001 19:34:45 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Matthew Dillon , John Baldwin , Bakul Shah , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <8700.1004132217@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Poul-Henning Kamp wrote: > Damn, signbug: [ ... ] > >I'm not going to ignore Matt on this subject until he comes to his > > s/not // Warning! Cycle counter moved backwards! 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:34:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C911837B409 for ; Fri, 26 Oct 2001 19:34:30 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9R2YT777473; Fri, 26 Oct 2001 22:34:29 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 22:34:29 -0400 (EDT) From: Garrett Wollman Message-Id: <200110270234.f9R2YT777473@khavrinen.lcs.mit.edu> To: Bill Fenner Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. In-Reply-To: <200110270146.SAA16181@windsor.research.att.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> <200110262209.f9QM9on75561@khavrinen.lcs.mit.edu> <200110270146.SAA16181@windsor.research.att.com> 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 < said: > The types declared [in ] are ... clock_t and time_t which are > arithmetic types capable of representing times. > Are you saying that C90 has an explicit requirement that time_t can't > be longer than 'long', or simply that C90 didn't have any types longer > than 'long'? Yes. C90 did not define any arithmetic types other than float, double, {signed,unsigned,} char, and {signed,unsigned} {short,long,} int. A later interpretation against C90 (requested by Clive Feather, IIRC) made it explicit that every typedef in the standard must resolve to a specific standard type of the indicated classification(s). C99 relaxes this requirement somewhat, by allowing additional arithmetic types, and by providing a new mechanism (intmax_t and the `j' format modifier) in which every implemented integral type is supported as a subset. Because C90 did not place any stricter requirement on time_t than that it be arithmetic, the POSIX review group did not feel it was necessary to further constrain the definition when aligning POSIX to C99; in essence, if a programmer was already prepared for time_t to be a long double, as required by the standard, then no additional work is needed if time_t is a long long or even a __fixpt128_t. However, the POSIX definition of ``seconds since the epoch'' implies an integer value, not floating-point, and even though the standard does not constrain time_t to be integer, almost all programs assume that it is. Thus, a C90 program which makes this assumption may fail if time_t is a new C99 type. For important POSIX types which were integers, the Austin group generally added a restriction to C90 types, in order to facilitate portability of programs from 1003.1-1996 and SUSv2, which did not have intmax_t or `j' formats, to the new standard (1003.1-2001) which does. For these reasons, I submit that FreeBSD should likewise not pull the rug out from under programmers who had no reason to ever expect time_t to be longer than a long (which, keep in mind, is the historical type going back to Seventh Edition UNIX). I've heard a lot of ``well, 5.0 is going to be such a huge leap that one more big change won't hurt so bad''. I disagree. I think 5.0 is already such a huge leap that many people will have a strong disincentive to adopt it at all, and every time we make that transition harder, more people will jump *off* the bandwagon. We already have several important, even revolutionary changes in the pipeline. But, if we continue to stage a revolution every quarter, 5.0 will never be shippable. This isn't to say that the groundwork can't be laid; I would not be opposed to seeing the kernel-internal timekeeping API improved with support for wider time_ts, and certainly we should update the filesystems and other important supporting infrastructure, but I don't believe that types should be changed on any existing platforms. It took five years to finally get rid of ; the assumption that |time_t| <= |long| is far more deeply in-grained in third-party software than ever was. (Which is why POsIX always has a huge flamefest at every revision about ``fixing'' the definition of Seconds Since the Epoch.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:42:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id B705737B405 for ; Fri, 26 Oct 2001 19:42:35 -0700 (PDT) Received: from dialup-209.245.143.103.dial1.sanjose1.level3.net ([209.245.143.103] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xJQc-0002SJ-00; Fri, 26 Oct 2001 19:42:30 -0700 Message-ID: <3BDA1F4B.91918606@mindspring.com> Date: Fri, 26 Oct 2001 19:43:23 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110262321.TAA14697@ajax.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Dag-Erling Smorgrav wrote: > Since you're so stuck up about standardization, go see POSIX or SUSv2 > or the Austin spec and show me a single reference to "nstime64_t" in > any one of those documents. Alternately, we could look at what the RFC says about the NFSv4 timestamps over the wire. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:47:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C2A8D37B401; Fri, 26 Oct 2001 19:47:40 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R2lYT42760; Fri, 26 Oct 2001 19:47:34 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 19:47:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270247.f9R2lYT42760@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: John Baldwin , Mike Smith , Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: 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 :John Baldwin writes: :> My bad. C90 requires that time_t fit into a long according to :> Garrett. : :Maybe it does. Maybe it doesn't. Chapter and verse, please. : :All I have is the final draft of C99, and all it says about the width :of time_t is that it is an arithmetic type "capable of representing :times" (7.23.1). There is no mention at all of the word "long" in :section 7.23. : :DES :-- :Dag-Erling Smorgrav - des@ofug.org .... so, anybody have the final word on this? Anybody have the official ('can't get on the web for free because the ISO people are putzes') standard? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:48: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 9210537B405; Fri, 26 Oct 2001 19:48:00 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9R2pwq02526; Fri, 26 Oct 2001 22:51:58 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Oct 2001 22:51:58 -0400 From: Mike Barcroft To: Mike Smith Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026225158.C2283@coffee.q9media.com> References: <200110270109.f9R19uv06023@mass.dis.org> <20011026215256.A2283@coffee.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026215256.A2283@coffee.q9media.com>; from mike@FreeBSD.ORG on Fri, Oct 26, 2001 at 09:52:56PM -0400 Organization: The FreeBSD Project 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 Mike Barcroft writes: > Mike Smith writes: > > I'll say it again, then. > > > > These programs should *not* be trying to use these functions. These functions > > are meant for manipulating time_t, which is a representation of "now". > > C99 defines clock_t and time_t as "arithmetic types capable of > representing times". I can't find any reference in POSIX or C99 that > time_t or its associated functions only deal with time as "now". > Could you please reference the source of this information. I discussed this with Mike on IRC, and his argument was geared more towards common usages of time_t rather than what the standards define them to be. POSIX and C99 are actually quite vague on the subject. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 19:48:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id EFF0D37B401; Fri, 26 Oct 2001 19:48:43 -0700 (PDT) Received: from dialup-209.245.143.103.dial1.sanjose1.level3.net ([209.245.143.103] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xJWd-0007Hb-00; Fri, 26 Oct 2001 19:48:43 -0700 Message-ID: <3BDA20C0.ED922810@mindspring.com> Date: Fri, 26 Oct 2001 19:49:36 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Matthew Dillon , arch@FreeBSD.ORG, Peter Wemm , Poul-Henning Kamp , Bakul Shah , Mike Smith , Dag-Erling Smorgrav Subject: Re: 64 bit times revisited.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 John Baldwin wrote: > You did read the e-mail from Garrett where either SUS or POSIX one requires > time_t to fit in a long? I.e. sizeof(time_t) <= sizeof(long). The basis for this is the atomic type argument. We already violate this one (in spades) for the off_t definition, which has the same requirement, yet is a "long long" on FreeBSD. Just food for thought... if the standard doesn't cover the case, it doesn't automatically mean that compliance is a good idea. We could always hack the compiler for an 128 bit "atomic" type, e.g. "very long long" or "long long long", and treat time_t the same way we treat off_t: with a nod and a wink to the standard, but incomplete actualtechnical compliance, if you were a C language lawyer... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 20:19:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 27EDB37B405 for ; Fri, 26 Oct 2001 20:19:54 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9R3JjJ77842; Fri, 26 Oct 2001 23:19:45 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 23:19:45 -0400 (EDT) From: Garrett Wollman Message-Id: <200110270319.f9R3JjJ77842@khavrinen.lcs.mit.edu> To: des@ofug.org Subject: Re: 64 bit times revisited.. In-Reply-To: References: <200110262321.TAA14697@ajax.cnchost.com> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org 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 In article you write: >Since you're so stuck up about standardization, go see POSIX or SUSv2 >or the Austin spec and show me a single reference to "nstime64_t" in >any one of those documents. POSIX has gone into a rathole every time it has tried to deal with the issue of time. Things like the broken ``Seconds Since the Epoch'' definition and `struct timespec' are what result. The real answer, as the people who have run the POSIX process would tell you, is very simple: come up with a proposal that works and reflects a concensus of implementors and end users, and then it may be appropriate for standardization. The next revision of POSIX will drop support for non-eight-bit bytes, not because the review committee wanted such a restriction, but because we did not want to invent a brand new set of interfaces, with no prior art, to deal with the discrepancies between traditional C/POSIX interfaces which did not make such an assumption, and newly-imported networking and UNIX interfaces which did. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 20:50:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1331037B505 for ; Fri, 26 Oct 2001 20:49:49 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9R3nf678020; Fri, 26 Oct 2001 23:49:41 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 23:49:41 -0400 (EDT) From: Garrett Wollman Message-Id: <200110270349.f9R3nf678020@khavrinen.lcs.mit.edu> To: des@ofug.org Subject: Re: 64 bit times revisited.. In-Reply-To: References: <200110270133.f9R1Xnv06295@mass.dis.org> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org 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 In article you write: >Chapter and verse, please. Not just a repetition of what somebody >else says may or may not be in C90. Cheap shot. See C90 defect report #67, . Although neither time_t nor ``arithmetic type'' is not explicitly mentioned in the defect report, the answers to Clive Feather's final two questions apply. time_t is defined by POSIX as representing times in seconds. (See XBD under .) Some interfaces are defined to use relative times measured in seconds (or smaller units when `struct timespec' is used); other interfaces are defined to use Seconds Since the Epoch (see XBD under the definition thereof). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 21:49:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9390E37B403 for ; Fri, 26 Oct 2001 21:49:03 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id AAA04886; Sat, 27 Oct 2001 00:48:55 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f9R4mSi87503; Sat, 27 Oct 2001 00:48:28 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15322.15516.770431.53945@grasshopper.cs.duke.edu> Date: Sat, 27 Oct 2001 00:48:28 -0400 (EDT) To: Peter Wemm Cc: arch@FreeBSD.ORG Reply-To: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011027015133.E4539380A@overcee.netplex.com.au> References: <200110270137.f9R1bVv06321@mass.dis.org> <20011027015133.E4539380A@overcee.netplex.com.au> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Peter Wemm writes: > > I doubt i386 32 bit apps will be around in 20 years. If it lives on, it > will be something like x86-64 or intel's spin on that. It too will have 64 > bit "long" and we can use a 64 bit time_t there. > > I dont see sufficient reason to inflict this pain on i386 in the name of > having the same size time_t. Having the same type (long) - yes, but using a > quad_t is just expensive overkill. > > I wish I hadn't even brought up the possibility of changing i386. I didn't > make it clear enough how much I hated the idea of it. If the alpha moves, I'd like to see i386 move too, just to ensure that it is done right & and alpha isn't left twisting in the wind... Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 23:23:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DDE1537B401 for ; Fri, 26 Oct 2001 23:23:23 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R6NLk43302; Fri, 26 Oct 2001 23:23:21 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 23:23:21 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270623.f9R6NLk43302@apollo.backplane.com> To: Garrett Wollman Cc: des@ofug.org, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110270133.f9R1Xnv06295@mass.dis.org> <200110270349.f9R3nf678020@khavrinen.lcs.mit.edu> 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 :In article you write: :>Chapter and verse, please. Not just a repetition of what somebody :>else says may or may not be in C90. : :Cheap shot. See C90 defect report #67, :. :Although neither time_t nor ``arithmetic type'' is not explicitly :mentioned in the defect report, the answers to Clive Feather's final :two questions apply. Take a look at this: http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/summary.htm This is the defect list for C99. It directly contradicts the reasoning in C90 defect report #67. Read #201 and #204. In the #201 the submitter tried to change the standard to require that size_t be no wider then unsigned long, but there was NO consensus to make this change. In #204 the submitter wants to explicitly allow size_t to be a 'long long'. #204 was incorporated into TC1. I found TC1 and looked it up, and it's there: "The types used for size_t and ptrdiff_t should not have an integer conversion rank greater then that of signed long unless the implementation supports objects large enough to make this necessary" Obviously they have caved in. 'long long' is being treated as an integral type. In a draft I found it defined as being an 'extended integral type'. This implies that it can be used for time_t. Unless something explicitly forbids it I think going to 64 bit time_t's in 5.0 is the correct action to take. ... still waiting for someone who has the latest C99 spec to look this stuff up :-) -Matt :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 23:36:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CF38A37B406; Fri, 26 Oct 2001 23:36:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R6aik43419; Fri, 26 Oct 2001 23:36:44 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 23:36:44 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270636.f9R6aik43419@apollo.backplane.com> To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <200110270240.f9R2eGv07017@mass.dis.org> 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 :Just to clarify, based on Peter's last mail. : :The proposal is not to change the size of time_t on x86, merely to :select a suitable size on new platforms so that we migrate in a :suitable fashion. : :This is fine, and a sensible idea. No, the current proposal... the one that has the most support (even if you discount me), is that we do not change time_t in 4.x, but in 5.x we change it to a 64 bit integer on all platforms (including IA32). This version has support from several camps. A bunch of 5.x guys like it because it means that all the 64 bit issues can be worked out by the larger community running on standard intel platforms. Other people like it because it (obviously) solves the 2038 problem. DES and I have allocated time to work on it starting mid-november. Nobody else has comitted time yet. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 26 23:43:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id E6E8E37B401; Fri, 26 Oct 2001 23:43:43 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9R6hhM46935; Fri, 26 Oct 2001 23:43:43 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 03830380A; Fri, 26 Oct 2001 23:43:43 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: <200110270636.f9R6aik43419@apollo.backplane.com> Date: Fri, 26 Oct 2001 23:43:42 -0700 From: Peter Wemm Message-Id: <20011027064343.03830380A@overcee.netplex.com.au> 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 Matthew Dillon wrote: > > :Just to clarify, based on Peter's last mail. > : > :The proposal is not to change the size of time_t on x86, merely to > :select a suitable size on new platforms so that we migrate in a > :suitable fashion. > : > :This is fine, and a sensible idea. > > No, the current proposal... the one that has the most support (even if > you discount me), is that we do not change time_t in 4.x, but in > 5.x we change it to a 64 bit integer on all platforms (including IA32). To be clear, I absolutely DO NOT support this. > This version has support from several camps. A bunch of 5.x guys like > it because it means that all the 64 bit issues can be worked out by > the larger community running on standard intel platforms. Other people > like it because it (obviously) solves the 2038 problem. I do not like it because it creates **additional** problems that will appear *only* on the i386. -current has got enough problems without bullet holes through the feet of the primary platform. I'm quite happy with changing from 'int' to 'long', but *not* quad. > DES and I have allocated time to work on it starting mid-november. > Nobody else has comitted time yet. > > -Matt > Matthew Dillon > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 0: 1:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 6FB1337B40B; Sat, 27 Oct 2001 00:01:10 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9R71AM46984; Sat, 27 Oct 2001 00:01:10 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D02E9380A; Sat, 27 Oct 2001 00:01:09 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: <20011027064343.03830380A@overcee.netplex.com.au> Date: Sat, 27 Oct 2001 00:01:09 -0700 From: Peter Wemm Message-Id: <20011027070109.D02E9380A@overcee.netplex.com.au> 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 Peter Wemm wrote: > Matthew Dillon wrote: > > > > :Just to clarify, based on Peter's last mail. > > : > > :The proposal is not to change the size of time_t on x86, merely to > > :select a suitable size on new platforms so that we migrate in a > > :suitable fashion. > > : > > :This is fine, and a sensible idea. > > > > No, the current proposal... the one that has the most support (even if > > you discount me), is that we do not change time_t in 4.x, but in > > 5.x we change it to a 64 bit integer on all platforms (including IA32). > > To be clear, I absolutely DO NOT support this. > > > This version has support from several camps. A bunch of 5.x guys like > > it because it means that all the 64 bit issues can be worked out by > > the larger community running on standard intel platforms. Other people > > like it because it (obviously) solves the 2038 problem. > > I do not like it because it creates **additional** problems that will > appear *only* on the i386. -current has got enough problems without > bullet holes through the feet of the primary platform. > > I'm quite happy with changing from 'int' to 'long', but *not* quad. As a followup, I wont fight to the bitter end if people are really convinced that it is a good idea and are going to firmly commit themselves to pick up the mess in both the src and entire ports tree. That means submitting patches back to the original distribution producers. But that the idea of it still gives me the creeps. I believe we'll be chasing bugs from this for years on the i386. > > DES and I have allocated time to work on it starting mid-november. > > Nobody else has comitted time yet. > > > > -Matt Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 0:37: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 6E92637B407; Sat, 27 Oct 2001 00:37:01 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9R7b1d94758; Sat, 27 Oct 2001 00:37:01 -0700 (PDT) (envelope-from obrien) Date: Sat, 27 Oct 2001 00:37:00 -0700 From: "David O'Brien" To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: 64 bit times revisited.. Message-ID: <20011027003700.A94651@dragon.nuxi.com> Reply-To: arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Oct 26, 2001 at 06:23:23PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Fri, Oct 26, 2001 at 06:23:23PM -0700, John Baldwin wrote: > C90 requires that time_t fit into a long according to Garrett. So? C90 is dead, long life C99. If we are going to give service to old specs, __P() needs to fully come back. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 0:47:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id D893737B401 for ; Sat, 27 Oct 2001 00:47:27 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9R7kaO94879; Sat, 27 Oct 2001 00:46:36 -0700 (PDT) (envelope-from obrien) Date: Sat, 27 Oct 2001 00:46:36 -0700 From: "David O'Brien" To: Giorgos Keramidas Cc: Jeroen Ruigrok/Asmodai , Lyndon Nerenberg , arch@FreeBSD.org Subject: Re: your mail Message-ID: <20011027004636.C94651@dragon.nuxi.com> Reply-To: arch@FreeBSD.org References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> <20011026153313.C96876@daemon.ninth-circle.org> <20011026192933.B16134@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011026192933.B16134@hades.hell.gr>; from charon@labs.gr on Fri, Oct 26, 2001 at 07:29:34PM +0300 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Fri, Oct 26, 2001 at 07:29:34PM +0300, Giorgos Keramidas wrote: > On Fri, Oct 26, 2001 at 03:33:13PM +0200, Jeroen Ruigrok/Asmodai wrote: > > >Based on this, what do you think about adding a NO_GNU_COMPLER_CMD_LINKS > > >macro to make.conf? If set, if would prevent the linking of cc -> > > >gcc and c++ -> g++, freeing up /usr/local/bin/g* for the site to > > >decide? (And I'm not tied to that horribly long macro name, either.) > > > > I would sooner prefer the other way around. Have gcc and g++ and have a > > knob to not create the gcc -> cc symlink. :) > > No please. > > I don't mind having both cc and gcc on my disks, but `cc' is the name > of the system compiler. Since our system compiler is gcc, I'd expect > both links to exist. Having a compiled named gcc is a GNU'ism that > has stuck with us now, but having a compiler called cc is something > that is part of what I've learned to call Unix. Please! No one has come close to suggesting 'cc' goes away as a command. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 0:50:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B05F837B406; Sat, 27 Oct 2001 00:50:30 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9R7oUq94908; Sat, 27 Oct 2001 00:50:30 -0700 (PDT) (envelope-from obrien) Date: Sat, 27 Oct 2001 00:50:30 -0700 From: "David O'Brien" To: Mike Smith Cc: arch@freebsd.org Subject: Re: time_t not to change size on x86 Message-ID: <20011027005030.D94651@dragon.nuxi.com> Reply-To: arch@freebsd.org Mail-Followup-To: Mike Smith , arch@freebsd.org References: <200110270240.f9R2eGv07017@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110270240.f9R2eGv07017@mass.dis.org>; from msmith@freebsd.org on Fri, Oct 26, 2001 at 07:40:16PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Fri, Oct 26, 2001 at 07:40:16PM -0700, Mike Smith wrote: > > Just to clarify, based on Peter's last mail. > > The proposal is not to change the size of time_t on x86, merely to > select a suitable size on new platforms so that we migrate in a > suitable fashion. What you describe is his *revamped* proposal. As one of the 3 in a private thread that started this, I speak with greater knowledge on what the proposal was. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 0:54:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 7258137B405; Sat, 27 Oct 2001 00:54:50 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9R7snr95012; Sat, 27 Oct 2001 00:54:49 -0700 (PDT) (envelope-from obrien) Date: Sat, 27 Oct 2001 00:54:48 -0700 From: "David O'Brien" To: Joe Abley Cc: Mike Barcroft , "Bruce A. Mah" , Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011027005448.E94651@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> <20011026131209.B355@coffee.q9media.com> <20011026221708.F59676@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011026221708.F59676@buffoon.automagic.org>; from jabley@automagic.org on Fri, Oct 26, 2001 at 10:17:08PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Fri, Oct 26, 2001 at 10:17:08PM -0400, Joe Abley wrote: > There is one more thing that is worth checking -- there are two > of my awk scripts involved in building bits of boot loader: > > sys/boot/common/merge_help.awk > sys/boot/ficl/softwords/softcore.awk Already dealt with. :-) [I ran with bawk as system awk for quite a while] ---------------------------- revision 1.5 date: 2000-11-14 21:02:49; author: obrien; state: Exp; lines: +2 -2 Don't use the Gawkism strftime(). Pass in the date stamp on the awk command line instead. ---------------------------- -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 0:58:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 179F037B401; Sat, 27 Oct 2001 00:58:34 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9R7wWq95069; Sat, 27 Oct 2001 00:58:32 -0700 (PDT) (envelope-from obrien) Date: Sat, 27 Oct 2001 00:58:32 -0700 From: "David O'Brien" To: Joe Abley Cc: Mike Barcroft , "Bruce A. Mah" , Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011027005832.F94651@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> <20011026131209.B355@coffee.q9media.com> <20011026221708.F59676@buffoon.automagic.org> <20011026222423.H59676@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011026222423.H59676@buffoon.automagic.org>; from jabley@automagic.org on Fri, Oct 26, 2001 at 10:24:24PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Fri, Oct 26, 2001 at 10:24:24PM -0400, Joe Abley wrote: > On Fri, Oct 26, 2001 at 10:17:08PM -0400, Joe Abley wrote: > > There are function definitions > > the second one uses [[:space:]]. There are function definitions > > used in softcore.awk, too. > > Ah, I just looked, and I see functions are supported in the > awk in question (assuming ports/lang/nawk is that awk). It is. > I will remove the outstanding gawkisms in these scripts now anyway and > submit a PR. What Gawk'isms still remain? nawk(bawk) runs fine on our base AWK scripts. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 1:12:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep13-int.chello.nl (amsfep13-int.chello.nl [213.46.243.23]) by hub.freebsd.org (Postfix) with ESMTP id 6E09237B401 for ; Sat, 27 Oct 2001 01:12:29 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep13-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011027081228.RBP18584.amsfep13-int.chello.nl@daemon.chronias.ninth-circle.org>; Sat, 27 Oct 2001 10:12:28 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9R897D11559; Sat, 27 Oct 2001 10:09:07 +0200 (CEST) (envelope-from asmodai) Date: Sat, 27 Oct 2001 10:09:07 +0200 From: Jeroen Ruigrok/Asmodai To: arch@FreeBSD.org Cc: Giorgos Keramidas , Lyndon Nerenberg Subject: Re: your mail Message-ID: <20011027100907.U96876@daemon.ninth-circle.org> References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> <20011026153313.C96876@daemon.ninth-circle.org> <20011026192933.B16134@hades.hell.gr> <20011027004636.C94651@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011027004636.C94651@dragon.nuxi.com> User-Agent: Mutt/1.3.22.1i Organisation: Ninth-Circle Enterprises 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 -On [20011027 10:06], David O'Brien (dev-null@NUXI.com) wrote: >> > I would sooner prefer the other way around. Have gcc and g++ and have a >> > knob to not create the gcc -> cc symlink. :) [Mistaken idea of removing cc] >Please! No one has come close to suggesting 'cc' goes away as a command. Exactly. Only reason I uttered my idea of: cc -> gcc And have that behaviour under a knob is that when I install other C compilers and they make a cc -> whatevercc in /usr/local/bin or something it will pick that cc up without mangling PATH back and forth. Not a big deal if it's there or not, just eases work a bit. But this knob would be on by default to make the symlinks. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ Any road leads to the end of the world... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 2:39:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 7B31E37B405 for ; Sat, 27 Oct 2001 02:39:25 -0700 (PDT) Received: (qmail 4482 invoked from network); 27 Oct 2001 09:39:24 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 09:39:24 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200110270636.f9R6aik43419@apollo.backplane.com> Date: Sat, 27 Oct 2001 02:39:24 -0700 (PDT) From: John Baldwin To: Matthew Dillon Subject: Re: time_t not to change size on x86 Cc: arch@FreeBSD.ORG, Mike Smith 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 On 27-Oct-01 Matthew Dillon wrote: > >:Just to clarify, based on Peter's last mail. >: >:The proposal is not to change the size of time_t on x86, merely to >:select a suitable size on new platforms so that we migrate in a >:suitable fashion. >: >:This is fine, and a sensible idea. > > No, the current proposal... the one that has the most support (even if > you discount me), is that we do not change time_t in 4.x, but in > 5.x we change it to a 64 bit integer on all platforms (including IA32). Actually, Peter listed like 3 proposals. I think changing the 386 would be the wrong thing to do. At the very least, it should be changed last. First change the 64-bit archs to use a 64-bit time_t (i..e., make time_t a 'long'). Then fix up the bugs that crop up from that. You can worry about hosing the ppc and i386 ports later. You may even want to make the ppc port use a 64-bit time_t since it is new, but I would leave i386 alone. That's my vote at least. You might want to count the actual votes flying around before assuming most people want to change time_t on the 386. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 3:36: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by hub.freebsd.org (Postfix) with ESMTP id 01A8937B403; Sat, 27 Oct 2001 03:36:00 -0700 (PDT) Received: from jaffacakes.freeserve.co.uk ([62.253.132.241]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20011027103558.HLZA13652.mta06-svc.ntlworld.com@jaffacakes.freeserve.co.uk>; Sat, 27 Oct 2001 11:35:58 +0100 Received: (from simonm@localhost) by jaffacakes.freeserve.co.uk (8.11.6/8.11.2) id f9RAZqT03278; Sat, 27 Oct 2001 11:35:52 +0100 (BST) (envelope-from simonm) To: Bill Fenner Cc: bde@zeta.org.au, rwatson@FreeBSD.ORG, bright@mu.org, arch@FreeBSD.ORG Subject: Re: Behavior of select() on pipes References: <200110262123.OAA13087@windsor.research.att.com> From: Simon Marlow Date: 27 Oct 2001 11:35:52 +0100 In-Reply-To: Bill Fenner's message of "Fri, 26 Oct 2001 14:23:17 -0700" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 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 Bill Fenner writes: > But the standard behavior makes O_NONBLOCK FIFOs relatively useless; > once you open it for read you have no way to find out when a writer > arrives without blocking. You have to become a writer yourself, which > may limit the usefulness of permissions on the FIFO (e.g. an rw-r----- > FIFO for messages from fenner to group foo; anyone in group foo could > become the reader but it's impossible for them to open for writing to > get around this behavior). I'd just like to second that. I've had particular problesm with FIFOs on FreeBSD in the threaded runtime system for our Haskell compiler (lang/ghc). The runtime system opens everything O_NONBLOCK, and manages blocking and thread scheduling internally, pretty much like libc_r I imagine. We have to tell people to open FIFOs in read/write mode on FreeBSD to work around this behaviour. (incidentally, doesn't libc_r have this problem?) FreeBSD might be correct w.r.t. the POSIX spec, but I think this is one of those cases where you've just got to admit that the behaviour mandated by the spec isn't useful. Cheers, Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 4:54:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id 2E9CF37B405 for ; Sat, 27 Oct 2001 04:54:03 -0700 (PDT) Received: (qmail 69938 invoked by uid 1000); 27 Oct 2001 11:54:02 -0000 Date: Sat, 27 Oct 2001 07:54:02 -0400 From: Joe Abley To: David O'Brien Cc: Mike Barcroft , "Bruce A. Mah" , Bill Fenner , arch@FreeBSD.ORG Subject: Re: import bawk? Re: NO_AWK Message-ID: <20011027075401.N59676@buffoon.automagic.org> References: <200110250153.f9P1rd0H071528@atg.aciworldwide.com> <20011024211434.G15052@elvis.mu.org> <20011025135022.A80517@dragon.nuxi.com> <200110252300.QAA27628@windsor.research.att.com> <20011026002659.H93553@coffee.q9media.com> <200110260512.f9Q5CFS40443@c527597-a.cstvl1.sfba.home.com> <20011026131209.B355@coffee.q9media.com> <20011026221708.F59676@buffoon.automagic.org> <20011026222423.H59676@buffoon.automagic.org> <20011027005832.F94651@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011027005832.F94651@dragon.nuxi.com> User-Agent: Mutt/1.3.22.1i 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 On Sat, Oct 27, 2001 at 12:58:32AM -0700, David O'Brien wrote: > On Fri, Oct 26, 2001 at 10:24:24PM -0400, Joe Abley wrote: > > > I will remove the outstanding gawkisms in these scripts now anyway and > > submit a PR. > > What Gawk'isms still remain? nawk(bawk) runs fine on our base AWK > scripts. Oh, that's ok then; I hadn't actually tried them when I wrote that. The character classes [:alpha:], [:space:], [:graph:] are not universally supported on different awks, and I was going to replace them with explicit regexps to make the scripts more portable. However, if they are supported by [bn]awk, then it makes the scripts much easier to read if we leave them in. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 5: 4:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9B42C37B408; Sat, 27 Oct 2001 05:04:09 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 0ED2914C2E; Sat, 27 Oct 2001 14:04:08 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: John Baldwin Cc: Matthew Dillon , arch@FreeBSD.ORG, Mike Smith Subject: Re: time_t not to change size on x86 References: From: Dag-Erling Smorgrav Date: 27 Oct 2001 14:04:06 +0200 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 John Baldwin writes: > Actually, Peter listed like 3 proposals. I think changing the 386 > would be the wrong thing to do. At the very least, it should be > changed last. First change the 64-bit archs to use a 64-bit time_t > (i..e., make time_t a 'long'). Then fix up the bugs that crop up > from that. You can worry about hosing the ppc and i386 ports later. > You may even want to make the ppc port use a 64-bit time_t since it > is new, but I would leave i386 alone. I'm willing to go along with this as a compromise. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 7:55:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DF49237B401 for ; Sat, 27 Oct 2001 07:55:25 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9REtFw86156; Sat, 27 Oct 2001 10:55:15 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 10:55:15 -0400 (EDT) From: Garrett Wollman Message-Id: <200110271455.f9REtFw86156@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <200110270623.f9R6NLk43302@apollo.backplane.com> References: <200110270133.f9R1Xnv06295@mass.dis.org> <200110270349.f9R3nf678020@khavrinen.lcs.mit.edu> <200110270623.f9R6NLk43302@apollo.backplane.com> 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 < said: > This is the defect list for C99. It directly contradicts the reasoning > in C90 defect report #67. C99 is not the same language as C90. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 8:41:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 063D637B403; Sat, 27 Oct 2001 08:41:25 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA02045; Sun, 28 Oct 2001 01:41:20 +1000 Date: Sun, 28 Oct 2001 01:40:22 +1000 (EST) From: Bruce Evans X-X-Sender: To: John Baldwin Cc: Dag-Erling Smorgrav , Mike Smith , Bakul Shah , Poul-Henning Kamp , Peter Wemm , , Matthew Dillon Subject: Re: 64 bit times revisited.. In-Reply-To: Message-ID: <20011028013151.Q96378-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 26 Oct 2001, John Baldwin wrote: > On 27-Oct-01 John Baldwin wrote: > > You did read the e-mail from Garrett where either SUS or POSIX one requires > > time_t to fit in a long? I.e. sizeof(time_t) <= sizeof(long). This means > ... > My bad. C90 requires that time_t fit into a long according to Garrett. POSIX > requires it to be either an integer or floating point with the fractional part > zero according to his mail as well. C90 only requres that time_t is an arithmetic type (anything from signed char to long double). POSIX also specifies a (wrong) representation (one that ensures that leap seconds can't possibly work). Changing time_t to long double would be interesting. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 8:45:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 79BA537B403 for ; Sat, 27 Oct 2001 08:45:51 -0700 (PDT) Received: (qmail 27461 invoked from network); 27 Oct 2001 15:45:49 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 15:45:49 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200110270623.f9R6NLk43302@apollo.backplane.com> Date: Sat, 27 Oct 2001 08:45:45 -0700 (PDT) From: John Baldwin To: Matthew Dillon Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG, des@ofug.org, Garrett Wollman 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 On 27-Oct-01 Matthew Dillon wrote: > >:In article you write: >:>Chapter and verse, please. Not just a repetition of what somebody >:>else says may or may not be in C90. >: >:Cheap shot. See C90 defect report #67, >:. >:Although neither time_t nor ``arithmetic type'' is not explicitly >:mentioned in the defect report, the answers to Clive Feather's final >:two questions apply. > > Take a look at this: > > http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/summary.htm > > This is the defect list for C99. It directly contradicts the reasoning > in C90 defect report #67. Read #201 and #204. In the #201 the submitter > tried to change the standard to require that size_t be no wider then > unsigned long, but there was NO consensus to make this change. In > #204 the submitter wants to explicitly allow size_t to be a 'long long'. > #204 was incorporated into TC1. I found TC1 and looked it up, and > it's there: > > "The types used for size_t and ptrdiff_t should not have an > integer conversion rank greater then that of signed long unless the > implementation supports objects large enough to make this necessary" > > Obviously they have caved in. 'long long' is being treated as an > integral type. In a draft I found it defined as being an > 'extended integral type'. This implies that it can be used for time_t. > Unless something explicitly forbids it I think going to 64 bit time_t's > in 5.0 is the correct action to take. > > ... still waiting for someone who has the latest C99 spec to look this > stuff up :-) Matt, just because C99 has changed doesn't mean we have to break C90. This is the difference between your baseline that you support vs. the newest stuff you support. Here's an example: for 4.x-stable, 4.1 is our baseline. This means that kernel modules, binaries, etc. from 4.1 should work on 4.4. Now, this doesn't mean that a program written for 4.4 can't use new features in 4.4, but 4.4 should not break backwards compatibility such that a 4.1 program no longer runs. Does this make sense? Ok, now go back through that and do s/4.1/C90/ and s/4.4/C99/. C99 is rather new to be requiring that all userland programs in the world be up to date to it, so C90 is a better baseline support. So you can add the extensions of C99 so a C99 program can run, but you can't break C90 compatibility by changing arbitrary things until we have actually changed our baseline from C90 to C99. It is probably too early to do that. Then again, you _did_ just break file system module compatibility on 4.x-stable, so maybe this is a foreign concept to you. However, you did justify that by saying there weren't any fs modules around, which makes me think you _do_ understand this issue. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 9:55:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1D67237B401; Sat, 27 Oct 2001 09:55:34 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RGtX947498; Sat, 27 Oct 2001 09:55:33 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 09:55:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200110271655.f9RGtX947498@apollo.backplane.com> To: John Baldwin Cc: arch@FreeBSD.ORG, des@ofug.org, Garrett Wollman Subject: Re: 64 bit times revisited.. References: 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 :Matt, just because C99 has changed doesn't mean we have to break C90. This is :the difference between your baseline that you support vs. the newest stuff you :... :John Baldwin -- http://www.FreeBSD.org/~jhb/ :PGP Key: http://www.baldwin.cx/~john/pgpkey.asc :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Who says we are breaking C90? So far nobody has posted anything from C90 that prevents us from changing time_t to a 64 bit int. Garrett's defect list posting is on very thin ice, it would take a whole lot of twisting to construe it as meaning that long long can't be used to define time_t. C90 is also over 10 years old. If these standards are supposed to reflect what people are doing with C, then obviously we want to use the latest one. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 10: 6:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2E50B37B403; Sat, 27 Oct 2001 10:06:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RH6ga47601; Sat, 27 Oct 2001 10:06:42 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 10:06:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200110271706.f9RH6ga47601@apollo.backplane.com> To: Peter Wemm Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> 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 :> > it because it means that all the 64 bit issues can be worked out by :> > the larger community running on standard intel platforms. Other people :> > like it because it (obviously) solves the 2038 problem. :> :> I do not like it because it creates **additional** problems that will :> appear *only* on the i386. -current has got enough problems without :> bullet holes through the feet of the primary platform. :> :> I'm quite happy with changing from 'int' to 'long', but *not* quad. : :As a followup, I wont fight to the bitter end if people are really :convinced that it is a good idea and are going to firmly commit themselves :to pick up the mess in both the src and entire ports tree. That means :submitting patches back to the original distribution producers. : :But that the idea of it still gives me the creeps. I believe we'll be :chasing bugs from this for years on the i386. : :> > DES and I have allocated time to work on it starting mid-november. :> > Nobody else has comitted time yet. :> > :> > -Matt : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au I think the absolute worst that can happen is that moving time_t to 64 bits will have the same sort of impact on ports that moving off_t to 64 bits had. I don't recall the off_t change as causing any significant pain. FreeBSD had it from the get-go, but most of our ports were compiled on systems with 32 bit off_t's. I think the reason for this can be attributed towards a general shift away from K&R and towards ANSI prototypes. Simply changing time_t from an int to a long for 64 bit architectures will not lessen the amount of work required to make it work properly on 32 bit architectures 'later'. I consider the approach worthless. If we are going to change time_t we damn well ought to fix it for all architectures all at once and get it over with. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 10:30:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 6C28A37B403; Sat, 27 Oct 2001 10:30:26 -0700 (PDT) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id f9RHUFG54230; Sat, 27 Oct 2001 19:30:15 +0200 (CEST) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id f9RHKDSe033969; Sat, 27 Oct 2001 19:20:15 +0200 (CEST)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id f9RHJvF10008; Sat, 27 Oct 2001 19:19:58 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id f9RHJod43483; Sat, 27 Oct 2001 19:19:51 +0200 (CEST) (envelope-from ticso) Date: Sat, 27 Oct 2001 19:19:49 +0200 From: Bernd Walter To: Matthew Dillon Cc: John Baldwin , Bakul Shah , Peter Wemm , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: 64 bit times revisited.. Message-ID: <20011027191949.A43183@cicely8.cicely.de> References: <200110262128.f9QLSX838762@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110262128.f9QLSX838762@apollo.backplane.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 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 On Fri, Oct 26, 2001 at 02:28:33PM -0700, Matthew Dillon wrote: > The phrase 'no freaking way' comes to mind. > > You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing > else. The *VAST* majority of programs only need seconds, it would be > utterly stupid to require that they mess around with some weird fixed > point quantity when all they want is seconds, no matter how supposedly > 'simple' that messing around is (i.e. '>> 64' is not acceptable). If you make it a union with 128bit and 2 64bit values you can access it simply by choosing the right name. I don't see a difference for second only programms compared to have the sub second part with different meanings. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 10:39: 3 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 7576037B401; Sat, 27 Oct 2001 10:39:00 -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 f9RHctE12711; Sat, 27 Oct 2001 11:38:55 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200110271738.f9RHctE12711@hunkular.glarp.com> To: Matthew Dillon Cc: Peter Wemm , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: Your message of "Sat, 27 Oct 2001 10:06:42 PDT." <200110271706.f9RH6ga47601@apollo.backplane.com> Date: Sat, 27 Oct 2001 11:38:55 -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 > Simply changing time_t from an int to a long for 64 bit architectures > will not lessen the amount of work required to make it work properly > on 32 bit architectures 'later'. I consider the approach worthless. > If we are going to change time_t we damn well ought to fix it for all > architectures all at once and get it over with. I agree. 64 bit time routines are need on i386 _today_, and the standard routines (localtime(), etc) are simply too useful to let languish in their current crippled state. brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 12:35:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1F5C937B403 for ; Sat, 27 Oct 2001 12:35:54 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9RJZpp88003; Sat, 27 Oct 2001 15:35:51 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 15:35:51 -0400 (EDT) From: Garrett Wollman Message-Id: <200110271935.f9RJZpp88003@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <200110271655.f9RGtX947498@apollo.backplane.com> References: <200110271655.f9RGtX947498@apollo.backplane.com> 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 < said: > Who says we are breaking C90? C90 does not have `long long', period, end of discussion. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 12:41:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 6C17F37B406; Sat, 27 Oct 2001 12:40:55 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9RJetp05459; Sat, 27 Oct 2001 12:40:55 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9RJfna00639; Sat, 27 Oct 2001 12:41:49 -0700 (PDT) (envelope-from marcel) Date: Sat, 27 Oct 2001 12:41:49 -0700 From: Marcel Moolenaar To: Peter Wemm Cc: Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <20011027124149.A486@dhcp01.pn.xcllnt.net> References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011027064343.03830380A@overcee.netplex.com.au> User-Agent: Mutt/1.3.21i 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 On Fri, Oct 26, 2001 at 11:43:42PM -0700, Peter Wemm wrote: > Matthew Dillon wrote: > > > > :Just to clarify, based on Peter's last mail. > > : > > :The proposal is not to change the size of time_t on x86, merely to > > :select a suitable size on new platforms so that we migrate in a > > :suitable fashion. > > : > > :This is fine, and a sensible idea. > > > > No, the current proposal... the one that has the most support (even if > > you discount me), is that we do not change time_t in 4.x, but in > > 5.x we change it to a 64 bit integer on all platforms (including IA32). > > To be clear, I absolutely DO NOT support this. Since we're counting votes: I too think we should leave the i386 alone. Changing time_t to long is a good "first step". Cross-platform inconsistencies (ie on-disk structures) are a preliminary to what we can expect if we do want to change the i386 *and* maintain backward compatibility. So, let's deal with that in a less destructive environment. If people still think we should move the i386 to a 64-bit time_t after we've dealed with the 64-bit archs, they can do so at their leasure, knowing that the road has been paved enough that you don't need off-road vehicles to cross the terrain. Personally I doubt it will be necessary... In the mean time, being able to use %ld for time_t is *very* convenient and truly MI. So: One step at a time, guys. Leave the i386 alone. If there's ever a need for making the switch on i386 (which I doubt) we can do that just as well at a later time, with a lot more insight than we have now... IMO; Let it be known. I step out of the discussion again. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 12:43:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 0C3C537B401 for ; Sat, 27 Oct 2001 12:43:12 -0700 (PDT) Received: from hades.hell.gr (patr530-a196.otenet.gr [212.205.215.196]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f9RJgu812053; Sat, 27 Oct 2001 22:42:57 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f9RJgvR35855; Sat, 27 Oct 2001 22:42:57 +0300 (EEST) (envelope-from charon@labs.gr) Date: Sat, 27 Oct 2001 22:42:56 +0300 From: Giorgos Keramidas To: Jeroen Ruigrok/Asmodai Cc: arch@FreeBSD.org, Lyndon Nerenberg Subject: Re: your mail Message-ID: <20011027224256.A35705@hades.hell.gr> References: <200110250222.f9P2M30H071765@atg.aciworldwide.com> <20011026153313.C96876@daemon.ninth-circle.org> <20011026192933.B16134@hades.hell.gr> <20011027004636.C94651@dragon.nuxi.com> <20011027100907.U96876@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011027100907.U96876@daemon.ninth-circle.org> User-Agent: Mutt/1.3.22.1i 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 On Sat, Oct 27, 2001 at 10:09:07AM +0200, Jeroen Ruigrok/Asmodai wrote: > > >Please! No one has come close to suggesting 'cc' goes away as a command. > > Exactly. > > Only reason I uttered my idea of: > > cc -> gcc > > And have that behaviour under a knob is that when I install other C > compilers and they make a cc -> whatevercc in /usr/local/bin or > something it will pick that cc up without mangling PATH back and forth. > > Not a big deal if it's there or not, just eases work a bit. But this > knob would be on by default to make the symlinks. In that case, I stand corrected :) If the default will be to still make a link cc -> gcc (and all their friends, like c++, etc), then this does not soundn like a bad idea. Not bad at all. -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 12:49: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id C8B3B37B403; Sat, 27 Oct 2001 12:49:01 -0700 (PDT) Received: from Hermes10.corp.disney.com (root@hermes10.corp.disney.com [153.7.110.102]) by mail.disney.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id f9RJlqQ14353; Sat, 27 Oct 2001 12:47:52 -0700 (PDT) Received: from [172.30.50.1] by hermes.corp.disney.com with ESMTP; Sat, 27 Oct 2001 12:48:09 -0700 Received: from plio.fan.fa.disney.com (plio.fan.fa.disney.com [153.7.118.2]) by pecos.fa.disney.com (8.11.3/8.11.3) with ESMTP id f9RJoP306709; Sat, 27 Oct 2001 12:50:26 -0700 (PDT) Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by plio.fan.fa.disney.com (8.9.2/8.9.2) with ESMTP id MAA01261; Sat, 27 Oct 2001 12:48:58 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from [172.30.46.51] by mercury.fan.fa.disney.com with ESMTP; Sat, 27 Oct 2001 12:48:56 -0700 Message-Id: <3BDB103F.763377D@disney.com> Date: Sat, 27 Oct 2001 12:51:28 -0700 From: Jim Pirzyk Organization: Walt Disney Feature Animation X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: Peter Wemm , Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Marcel Moolenaar wrote: > On Fri, Oct 26, 2001 at 11:43:42PM -0700, Peter Wemm wrote: > > Matthew Dillon wrote: > > > > > > :Just to clarify, based on Peter's last mail. > > > : > > > :The proposal is not to change the size of time_t on x86, merely to > > > :select a suitable size on new platforms so that we migrate in a > > > :suitable fashion. > > > : > > > :This is fine, and a sensible idea. > > > > > > No, the current proposal... the one that has the most support (even if > > > you discount me), is that we do not change time_t in 4.x, but in > > > 5.x we change it to a 64 bit integer on all platforms (including IA32). > > > > To be clear, I absolutely DO NOT support this. > > Since we're counting votes: I too think we should leave the i386 alone. > > Changing time_t to long is a good "first step". Cross-platform > inconsistencies (ie on-disk structures) are a preliminary to > what we can expect if we do want to change the i386 *and* > maintain backward compatibility. So, let's deal with that in > a less destructive environment. If people still think we should > move the i386 to a 64-bit time_t after we've dealed with the > 64-bit archs, they can do so at their leasure, knowing that the > road has been paved enough that you don't need off-road vehicles > to cross the terrain. Personally I doubt it will be necessary... > > In the mean time, being able to use %ld for time_t is *very* > convenient and truly MI. > > So: One step at a time, guys. Leave the i386 alone. If there's ever > a need for making the switch on i386 (which I doubt) we can do that > just as well at a later time, with a lot more insight than we have > now... > > IMO; Let it be known. I step out of the discussion again. I too agree that we should change time_t on the 64bit platforms and leave the i386 platform alone. I do really doubt that there will be many of those running in 2038, so what does it buy us? Yes it does buy us the same field size on all platforms, but at the expense of not being able to use %ld for our printf's everywhere. I do not see it really gives us the platform independance if we have to #ifdef alpha* in our printf code. - JimP * alpha being just a repreentation of a 64 bit FreeBSD platform. -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13: 7:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 04F0637B403 for ; Sat, 27 Oct 2001 13:07:26 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9RK7NG88372; Sat, 27 Oct 2001 16:07:23 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 16:07:23 -0400 (EDT) From: Garrett Wollman Message-Id: <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> To: dillon@apollo.backplane.com Subject: Re: time_t not to change size on x86 In-Reply-To: <200110271706.f9RH6ga47601@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org 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 In article <200110271706.f9RH6ga47601@apollo.backplane.com> you write: [quoting Peter Wemm] >:But that the idea of it still gives me the creeps. I believe we'll be >:chasing bugs from this for years on the i386. For what it's worth, I agree strongly with Peter. Perhaps more than strongly; I think it's absolutely insane to even contemplate changing time_t on IA-32 over the course of anything less than a decade. Times *are* that critical. > I think the absolute worst that can happen is that moving time_t to > 64 bits will have the same sort of impact on ports that moving off_t to > 64 bits had. Not so. You've missed one extremely important issue: off_t was not passed by reference in any standard interface. Indeed, it was a new invention only a few years old. time_t is passed by reference in all standard interfaces except mktime(). Furthermore, many other systems had longer-than-long off_t (that's what the whole Large File Summit thing was about); there are NO other systems which have longer-than-long time_t. In those systems, which actually cared about standards compliance, the *32/*64 and EOVERFLOW hacks introduced by the LFS were used so that standard-compliant applications would not break. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13:12:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 4E23137B405; Sat, 27 Oct 2001 13:12:05 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9RKC4M51299; Sat, 27 Oct 2001 13:12:04 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 294B839F0; Sat, 27 Oct 2001 13:12:03 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: <200110271706.f9RH6ga47601@apollo.backplane.com> Date: Sat, 27 Oct 2001 13:12:02 -0700 From: Peter Wemm Message-Id: <20011027201203.294B839F0@overcee.netplex.com.au> 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 Matthew Dillon wrote: > :> > it because it means that all the 64 bit issues can be worked out by > :> > the larger community running on standard intel platforms. Other peo ple > :> > like it because it (obviously) solves the 2038 problem. > :> > :> I do not like it because it creates **additional** problems that will > :> appear *only* on the i386. -current has got enough problems without > :> bullet holes through the feet of the primary platform. > :> > :> I'm quite happy with changing from 'int' to 'long', but *not* quad. > : > :As a followup, I wont fight to the bitter end if people are really > :convinced that it is a good idea and are going to firmly commit themselves > :to pick up the mess in both the src and entire ports tree. That means > :submitting patches back to the original distribution producers. > : > :But that the idea of it still gives me the creeps. I believe we'll be > :chasing bugs from this for years on the i386. > : > :> > DES and I have allocated time to work on it starting mid-november. > :> > Nobody else has comitted time yet. > :> > > :> > -Matt > : > :Cheers, > :-Peter > :-- > :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > > I think the absolute worst that can happen is that moving time_t to > 64 bits will have the same sort of impact on ports that moving off_t to > 64 bits had. I don't recall the off_t change as causing any significant > pain. FreeBSD had it from the get-go, but most of our ports were > compiled on systems with 32 bit off_t's. Glad you mentioned the off_t problem.. We're *still* finding off_t bugs in *OUR OWN CODE*!! How long has off_t been long long? Nearly 8 years now and we're *still* finding them! Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13:14:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1CC5C37B403; Sat, 27 Oct 2001 13:14:47 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RKEkj56354; Sat, 27 Oct 2001 13:14:46 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 13:14:46 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272014.f9RKEkj56354@apollo.backplane.com> To: Peter Wemm Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <20011027201203.294B839F0@overcee.netplex.com.au> 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 :> :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au :> :> I think the absolute worst that can happen is that moving time_t to :> 64 bits will have the same sort of impact on ports that moving off_t to :> 64 bits had. I don't recall the off_t change as causing any significant :> pain. FreeBSD had it from the get-go, but most of our ports were :> compiled on systems with 32 bit off_t's. : :Glad you mentioned the off_t problem.. We're *still* finding off_t bugs :in *OUR OWN CODE*!! How long has off_t been long long? Nearly 8 years now :and we're *still* finding them! : :Cheers, :-Peter And I'm sure there are still K&R problems too. The point is that off_t being 64 bits has not posed a serious problem in at least 5 years, probably longer. It's completely off the radar screen. Are you seriously proposing that we change off_t back to 32 bits because of the minor little off-the-radar-almost-don't-matter bugs that come up every now and again? No? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13:17:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id E161637B401; Sat, 27 Oct 2001 13:17:27 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9RKGnS19525; Sat, 27 Oct 2001 22:16:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: Your message of "Sat, 27 Oct 2001 13:12:02 PDT." <20011027201203.294B839F0@overcee.netplex.com.au> Date: Sat, 27 Oct 2001 22:16:48 +0200 Message-ID: <19523.1004213808@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <20011027201203.294B839F0@overcee.netplex.com.au>, Peter Wemm writes : >Glad you mentioned the off_t problem.. We're *still* finding off_t bugs >in *OUR OWN CODE*!! How long has off_t been long long? Nearly 8 years now >and we're *still* finding them! Which clearly points out the real problem: We need a language with better type-checking than C, (but before anybody suggest it: "...but without all the excess luggage and emotional hangups of C++") -- 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 freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13:29:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B39C637B403 for ; Sat, 27 Oct 2001 13:29:19 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RKTIi56468; Sat, 27 Oct 2001 13:29:18 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 13:29:18 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272029.f9RKTIi56468@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> 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 :off_t was not passed by reference in any standard interface. Indeed, :it was a new invention only a few years old. So? A pass-by-reference sizing problem is at least as bad as a pass-by-value sizing problem. C promotes char's and short's to ints when passing them as parameters, but it doesn't automatically promote anything to long int. :time_t is passed by reference in all standard interfaces except :mktime(). So? That's why we have to roll the syscalls and major library rev. Older binaries will still run just fine. :Furthermore, many other systems had longer-than-long off_t (that's :what the whole Large File Summit thing was about); there are NO other :systems which have longer-than-long time_t. In those systems, which :actually cared about standards compliance, the *32/*64 and EOVERFLOW :hacks introduced by the LFS were used so that standard-compliant :applications would not break. : :-GAWollman I think the discussion in regards to sizeof(time_t) > sizeof(long) is a valid one, but I don't see it as a show stopper. I had issues with 2038 15-20 years ago, I have issues with 2038 now. I am not going to wait until 2037 for the problem to be fixed. 5.0 is the perfect place to fix it, and it needs to be fixed for IA32 as well as for everything else because I'm fraggin sick and tired of people whining about it for two decades and not particularly interested in hearing more whining for the next two decades. If time_t can be a double, it damn well can be an int64_t. -Matt :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13:49:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 70A2137B405 for ; Sat, 27 Oct 2001 13:49:12 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9RKn9K88676; Sat, 27 Oct 2001 16:49:09 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 16:49:09 -0400 (EDT) From: Garrett Wollman Message-Id: <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 In-Reply-To: <200110272029.f9RKTIi56468@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> 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 < said: > If time_t can be a double, it damn > well can be an int64_t. No, it can't. RTFS. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13:55:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 0181137B403 for ; Sat, 27 Oct 2001 13:55:24 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9RKtFa56104; Sat, 27 Oct 2001 16:55:15 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <19523.1004213808@critter.freebsd.dk> References: <19523.1004213808@critter.freebsd.dk> Date: Sat, 27 Oct 2001 16:55:13 -0400 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: time_t not to change size on x86 Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 10:16 PM +0200 10/27/01, Poul-Henning Kamp wrote: >Peter Wemm writes: > > Glad you mentioned the off_t problem.. We're *still* finding off_t > > bugs in *OUR OWN CODE*!! How long has off_t been long long? > > Nearly 8 years now and we're *still* finding them! > >Which clearly points out the real problem: We need a language with >better type-checking than C, (but before anybody suggest it: "...but >without all the excess luggage and emotional hangups of C++") Now that's getting into MAJOR bikeshed territory! :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 13:56:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CFD1437B427 for ; Sat, 27 Oct 2001 13:56:45 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RKuiZ64324; Sat, 27 Oct 2001 13:56:44 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 13:56:44 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272056.f9RKuiZ64324@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> 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 : :< said: : :> If time_t can be a double, it damn :> well can be an int64_t. : :No, it can't. RTFS. : :-GAWollman We are still waiting to see what both C90 and C99 say. As DES would say, quote the standard. So far nothing I've heard prevents us from being able to make time_t a 64 bit int on IA32. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14: 9: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 223E937B405 for ; Sat, 27 Oct 2001 14:08:58 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id OAA24333; Sat, 27 Oct 2001 14:08:39 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda24331; Sat Oct 27 14:08:32 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id f9RL8WQ43030; Sat, 27 Oct 2001 14:08:32 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdl43028; Sat Oct 27 14:07:35 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id f9RL7Yx81849; Sat, 27 Oct 2001 14:07:34 -0700 (PDT) Message-Id: <200110272107.f9RL7Yx81849@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdX81845; Sat Oct 27 14:07:25 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Garance A Drosihn Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-reply-to: Your message of "Sat, 27 Oct 2001 16:55:13 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Oct 2001 14:07:25 -0700 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 In message , Garance A Drosihn writes: > At 10:16 PM +0200 10/27/01, Poul-Henning Kamp wrote: > >Peter Wemm writes: > > > Glad you mentioned the off_t problem.. We're *still* finding off_t > > > bugs in *OUR OWN CODE*!! How long has off_t been long long? > > > Nearly 8 years now and we're *still* finding them! > > > >Which clearly points out the real problem: We need a language with > >better type-checking than C, (but before anybody suggest it: "...but > >without all the excess luggage and emotional hangups of C++") > > Now that's getting into MAJOR bikeshed territory! :-) Paint it green please. :) Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14:10:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id CD2C237B403 for ; Sat, 27 Oct 2001 14:10:44 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9RLAeW91039; Sat, 27 Oct 2001 17:10:40 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 17:10:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 In-Reply-To: <200110272056.f9RKuiZ64324@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> 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 < said: > We are still waiting to see what both C90 and C99 say. No, you are not. You have already seen what C90 says: the committee responses to defect reports are the official interpretations of the Standard. The set of types defined in C90 is exhaustive; implementations are not permitted to extend it in a way which would be visible to a strictly conforming application. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14:15: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F319937B401 for ; Sat, 27 Oct 2001 14:14:58 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RLEwv64429; Sat, 27 Oct 2001 14:14:58 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 14:14:58 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272114.f9RLEwv64429@apollo.backplane.com> To: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 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 Hmm. This is interesting. So far all the time code I've looked at in libc is already explicitly written to operate with a 64 bit time_t and there do not appear to be any (so far) dependancies on 'long' or any other int type assumptions. Methinks a couple of people have already taken a couple of passes on the code. The only real work is going to be rolling the syscalls and some relatively minor adjustments to UFS. The rest of the kernel appears to be clean though I will need to take a second pass on netinet6 and nwfs. Now on to auditing the library code... -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14:16:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 601F837B401 for ; Sat, 27 Oct 2001 14:16:41 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RLGeg64445; Sat, 27 Oct 2001 14:16:40 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 14:16:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272116.f9RLGeg64445@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> 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 : :< said: : :> We are still waiting to see what both C90 and C99 say. : :No, you are not. You have already seen what C90 says: the committee :responses to defect reports are the official interpretations of the :Standard. The set of types defined in C90 is exhaustive; :implementations are not permitted to extend it in a way which would be :visible to a strictly conforming application. : :-GAWollman Garrett, are you seriously suggesting that we remove long int and change off_t back to 32 bits? Because if you aren't this argument doesn't hold any water for not converting time_t. What does C99 say? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14:27:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id F24FC37B401; Sat, 27 Oct 2001 14:27:28 -0700 (PDT) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id f9RLQSw43097; Sat, 27 Oct 2001 14:26:28 -0700 (PDT) (envelope-from jkh@winston.freebsd.org) To: Poul-Henning Kamp Cc: Peter Wemm , Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: Message from Poul-Henning Kamp of "Sat, 27 Oct 2001 22:16:48 +0200." <19523.1004213808@critter.freebsd.dk> Date: Sat, 27 Oct 2001 14:26:28 -0700 Message-ID: <43093.1004217988@winston.freebsd.org> From: Jordan Hubbard 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 > type-checking than C, (but before anybody suggest it: "...but without all > the excess luggage and emotional hangups of C++") Even implying that C++ simply has emotional hangups is like saying that Jeffrey Dahmer merely had an eating disorder. :) That language is nothing less than a distillation of raw evil. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14:31:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7D47F37B401 for ; Sat, 27 Oct 2001 14:31:27 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9RLVPU91171; Sat, 27 Oct 2001 17:31:25 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 17:31:25 -0400 (EDT) From: Garrett Wollman Message-Id: <200110272131.f9RLVPU91171@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 In-Reply-To: <200110272116.f9RLGeg64445@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> <200110272116.f9RLGeg64445@apollo.backplane.com> 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 < said: > Garrett, are you seriously suggesting that we remove long int > and change off_t back to 32 bits? Because if you aren't this > argument doesn't hold any water for not converting time_t. off_t is not a C type, it is a POSIX type. time_t is a C type. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14:34:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 9172B37B401 for ; Sat, 27 Oct 2001 14:34:08 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9RLY8M51578 for ; Sat, 27 Oct 2001 14:34:08 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 3E3B239F3; Sat, 27 Oct 2001 14:34:07 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: <200110272114.f9RLEwv64429@apollo.backplane.com> Date: Sat, 27 Oct 2001 14:34:07 -0700 From: Peter Wemm Message-Id: <20011027213407.3E3B239F3@overcee.netplex.com.au> 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 Matthew Dillon wrote: > Hmm. This is interesting. So far all the time code I've > looked at in libc is already explicitly written to operate > with a 64 bit time_t and there do not appear to be any (so > far) dependancies on 'long' or any other int type assumptions. > > Methinks a couple of people have already taken a couple of > passes on the code. Well, time_t used to be 'long', which is 64 bits on 64 bit platforms so it had to be safe. But thats not the issue. The issue is 'long long' and missing prototypes, &long vs &time_t etc. We cant force the rest of the world to compile everything with -Wmissing-prototypes etc. > The only real work is going to be > rolling the syscalls and some relatively minor adjustments > to UFS. The rest of the kernel appears to be clean though > I will need to take a second pass on netinet6 and nwfs. Dont mess with UFS! Let Kirk do it properly with UFS2. We dont need future timestamps in UFS, we actually do have 37 years to solve this one. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 14:51:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1854F37B406; Sat, 27 Oct 2001 14:51:53 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9RLpla136406; Sat, 27 Oct 2001 17:51:47 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011027124149.A486@dhcp01.pn.xcllnt.net> References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net> Date: Sat, 27 Oct 2001 17:51:42 -0400 To: Marcel Moolenaar , Peter Wemm From: Garance A Drosihn Subject: Re: time_t not to change size on x86, votes Cc: Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 12:41 PM -0700 10/27/01, Marcel Moolenaar wrote: >Since we're counting votes: I too think we should leave the >i386 alone. > >Changing time_t to long is a good "first step". [..etc..] > >In the mean time, being able to use %ld for time_t is *very* >convenient and truly MI. So much has been said in this thread, and so many suggestions offered, that I am not sure anyone could reliably say where people's votes are. Here is a suggested way to think about the votes. Let's pick a scale from 1 to 5, where 1 = "I will fight against this change with all the keys on my keyboard", 3 = "I am basically neutral on the idea", and 5 = "I am certain that the freebsd project should make this change". Now use that scale to vote for the following list of suggested changes. Each item in the list is for one specific change, and each would be voted on separately. a) For the up-and-coming 64-bit platforms (sparc64, IA-64), FreeBSD 5.0-release should have a 64-bit value for time_t. b) For the up-and-coming 32-bit platforms (PowerPC), FreeBSD 5.0-release should have a 64-bit value for time_t. c) For the existing 32-bit platform (i386), FreeBSD 5.0-release should have a 64-bit value. d) For all 32-bit platforms (PowerPC, i386), iff FreeBSD 5.0-release continues to be a 32-bit value, then it should be called 'long' instead of 'int'. My own votes are: a) 5.0 - Even though I have read all the messages in this thread, I have not seen one convincing argument for bringing these new platforms up on a 32-bit time_t, which then means we will have to plan a migration to 64-bit time_t at some later date. b) 4.0 - this does seem like a good idea to me, but I can also live with a 32-bit time_t on 32-bit platforms. c) 3.1 - given my votes for a & b, I think I would slightly prefer to have a 64-bit time_t on i386. I can also see that even if we do want this, it might still be better to wait until 6.0 or later to do it. d) 4.9 - if-and-only-if we are going to have any 32-bit time_t's, then it makes the most sense (to me) if they are explicitly 'long' and not 'int'. Note that I am not debating what any C standards say, and I am not casting aspersions on what anyone else thinks we should do. Given that the C standards are so pathetic on this, I recognize that no matter WHAT we do, it will not be a perfect solution. So, I am just voting for what I think would be the best action for the FreeBSD project to take at this time. I don't really expect anyone to drop what they are doing based on my vote, but I thought that presenting an explicit list of "what to vote on" might be helpful to this debate. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 15:16:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B88D837B401 for ; Sat, 27 Oct 2001 15:16:26 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RMGQV64611; Sat, 27 Oct 2001 15:16:26 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 15:16:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272216.f9RMGQV64611@apollo.backplane.com> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <20011027213407.3E3B239F3@overcee.netplex.com.au> 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 : :Well, time_t used to be 'long', which is 64 bits on 64 bit platforms :so it had to be safe. : :But thats not the issue. The issue is 'long long' and missing prototypes, :&long vs &time_t etc. We cant force the rest of the world to compile :everything with -Wmissing-prototypes etc. We don't have to. Back in the off_t days a lot of people were not using prototyped headers or were 'extern'ing C library routines themselves rather then #includ'ing the correct header. That did create a problem. But that was a decade ago. Nearly all the code we care about today is using prototypes and include files properly. off_t (not just on FreeBSD) and multi-platform users forced them to start doing it right. It isn't nearly the issue today that it was years ago. Today, 64 bit integer types on 32 bit platforms is an accepted use of C. They are considered to be and used as basic integer types. :> The only real work is going to be :> rolling the syscalls and some relatively minor adjustments :> to UFS. The rest of the kernel appears to be clean though :> I will need to take a second pass on netinet6 and nwfs. : :Dont mess with UFS! Let Kirk do it properly with UFS2. We dont need :future timestamps in UFS, we actually do have 37 years to solve this one. : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au Huh? There is very little to mess with. UFS already has the necessary fields and they are unused (FreeBSD forces the nanotime fields to 0), and it can be made 100% backwards compatible. But, that said, I agree that we don't need to make any changes to UFS now other then to make sure we convert between 32 and 64 bit times properly in stat(). Neither do we need to move UFS to 64 bit block numbers in tandem with 64 bit timestamps. They are completely separate issues. UFS is a non-issue. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 15:17:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 047A137B405 for ; Sat, 27 Oct 2001 15:17:37 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RMHZ164628; Sat, 27 Oct 2001 15:17:35 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 15:17:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272217.f9RMHZ164628@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> <200110272116.f9RLGeg64445@apollo.backplane.com> <200110272131.f9RLVPU91171@khavrinen.lcs.mit.edu> 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 : :< said: : :> Garrett, are you seriously suggesting that we remove long int :> and change off_t back to 32 bits? Because if you aren't this :> argument doesn't hold any water for not converting time_t. : :off_t is not a C type, it is a POSIX type. time_t is a C type. : :-GAWollman Fine. But it doesn't change anything. 64 bit integers are used everywhere now a days and accepted (and used as) as a basic integer type. C90 is ten years old and just doesn't apply any more. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 15:20:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6B65B37B403 for ; Sat, 27 Oct 2001 15:20:49 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RMKmH64657; Sat, 27 Oct 2001 15:20:48 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 15:20:48 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272220.f9RMKmH64657@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> 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 : :< said: : :> We are still waiting to see what both C90 and C99 say. : :No, you are not. You have already seen what C90 says: the committee :responses to defect reports are the official interpretations of the :Standard. The set of types defined in C90 is exhaustive; :implementations are not permitted to extend it in a way which would be :visible to a strictly conforming application. : :-GAWollman I already responded to the C90 stuff you posted. Your reasoning and the elements you posted were extremely weak arguments, frankly. I responded with excerpts from the defect list for C99's which I think makes it quite clear that people consider C90 broken. So frankly, Garrett, I don't really give a damn what a ten-year old standard says. 64 bit integer types on 32 bit platforms are totally acceptable today. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 16:30:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 51F2937B403 for ; Sat, 27 Oct 2001 16:30:24 -0700 (PDT) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id f9RNUIt55815; Sun, 28 Oct 2001 01:30:18 +0200 (CEST) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id f9RNTDSe037209; Sun, 28 Oct 2001 01:29:13 +0200 (CEST)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id f9RNStF10374; Sun, 28 Oct 2001 01:28:56 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id f9RNSmT45324; Sun, 28 Oct 2001 01:28:49 +0200 (CEST) (envelope-from ticso) Date: Sun, 28 Oct 2001 01:28:47 +0200 From: Bernd Walter To: Peter Wemm Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <20011028012847.B44659@cicely8.cicely.de> References: <200110272114.f9RLEwv64429@apollo.backplane.com> <20011027213407.3E3B239F3@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011027213407.3E3B239F3@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 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 On Sat, Oct 27, 2001 at 02:34:07PM -0700, Peter Wemm wrote: > Matthew Dillon wrote: > > Hmm. This is interesting. So far all the time code I've > > looked at in libc is already explicitly written to operate > > with a 64 bit time_t and there do not appear to be any (so > > far) dependancies on 'long' or any other int type assumptions. > > > > Methinks a couple of people have already taken a couple of > > passes on the code. > > Well, time_t used to be 'long', which is 64 bits on 64 bit platforms > so it had to be safe. At least on current it's defined as int. NetBSD does define long, but also use int on 64 bit platforms. > > The only real work is going to be > > rolling the syscalls and some relatively minor adjustments > > to UFS. The rest of the kernel appears to be clean though > > I will need to take a second pass on netinet6 and nwfs. > > Dont mess with UFS! Let Kirk do it properly with UFS2. We dont need > future timestamps in UFS, we actually do have 37 years to solve this one. Agreed. Removing the blocknumber limit is much more important until then. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 17:36:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 106C537B406 for ; Sat, 27 Oct 2001 17:36:54 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9S0arb89926; Sat, 27 Oct 2001 17:36:53 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 17:36:53 -0700 (PDT) From: Matthew Dillon Message-Id: <200110280036.f9S0arb89926@apollo.backplane.com> To: arch@freebsd.org Subject: Re: 64 bit times revisited.. 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 World will build with 64 bit time_t. There was one fatal error in /usr.sbin/md5/md5.c. I really expected there to be more problems but it looks like most of the programs are type-agnostic. 'dd' converts time to doubles, for example, before it does anything. I'm doing a more complete audit now. There will certainly be a number of programs which truncate to sizeof(long) or sizeof(void *) or sizeof(int). 'make' does all three :-) I expect there to be others, but nothing that we would have to fix immediately (though I will fix them as I come across them). So far it's been amazingly painless. I really don't think this is going to be as big a deal as some people think (or even as big a deal as I thought it would be, I'm already half way there!). The next step for me is to write the syscall roll functions and test a 64 bit time_t kernel with a 32 bit time_t userland. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 17:55:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E50F837B405 for ; Sat, 27 Oct 2001 17:55:35 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9S0tZ184290; Sat, 27 Oct 2001 17:55:35 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 17:55:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200110280055.f9S0tZ184290@apollo.backplane.com> To: arch@FreeBSD.ORG Subject: need review make time_t type agnostic changes 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 Here is a diff for review to remove int truncation of time in make. There is still an issue in that the archive format can only handle 11 useful digits, so its only good for 10^11 seconds, but that's the way it goes. I didn't even know make *tried* to read the table of contents for an archive! Must be some weird mis-feature. In anycase, make needed to be fixed anyway since half the routines cast time_t to an int, which breaks any conceivable notion of the proper handling of time_t. -Matt Index: arch.c =================================================================== RCS file: /home/ncvs/src/usr.bin/make/arch.c,v retrieving revision 1.15.2.1 diff -u -r1.15.2.1 arch.c --- arch.c 2001/02/13 03:13:57 1.15.2.1 +++ arch.c 2001/10/28 00:48:29 @@ -941,7 +941,7 @@ &arh, "r+"); efree(p1); efree(p2); - snprintf(arh.ar_date, sizeof(arh.ar_date), "%-12ld", (long) now); + snprintf(arh.ar_date, sizeof(arh.ar_date), "%-12qd", (quad_t) now); if (arch != NULL) { (void)fwrite ((char *)&arh, sizeof (struct ar_hdr), 1, arch); @@ -974,7 +974,7 @@ struct utimbuf times; /* Times for utime() call */ arch = ArchFindMember (gn->path, RANLIBMAG, &arh, "r+"); - snprintf(arh.ar_date, sizeof(arh.ar_date), "%-12ld", (long) now); + snprintf(arh.ar_date, sizeof(arh.ar_date), "%-12qd", (quad_t) now); if (arch != NULL) { (void)fwrite ((char *)&arh, sizeof (struct ar_hdr), 1, arch); @@ -1000,12 +1000,12 @@ * *----------------------------------------------------------------------- */ -int +time_t Arch_MTime (gn) GNode *gn; /* Node describing archive member */ { struct ar_hdr *arhPtr; /* Header of desired member */ - int modTime; /* Modification time as an integer */ + time_t modTime; /* Modification time as an integer */ char *p1, *p2; arhPtr = ArchStatMember (Var_Value (ARCHIVE, gn, &p1), @@ -1015,7 +1015,7 @@ efree(p2); if (arhPtr != NULL) { - modTime = (int) strtol(arhPtr->ar_date, NULL, 10); + modTime = (time_t) strtoq(arhPtr->ar_date, NULL, 10); } else { modTime = 0; } @@ -1038,7 +1038,7 @@ * *----------------------------------------------------------------------- */ -int +time_t Arch_MemMTime (gn) GNode *gn; { @@ -1176,12 +1176,12 @@ } else { #ifdef RANLIBMAG struct ar_hdr *arhPtr; /* Header for __.SYMDEF */ - int modTimeTOC; /* The table-of-contents's mod time */ + time_t modTimeTOC; /* The table-of-contents's mod time */ arhPtr = ArchStatMember (gn->path, RANLIBMAG, FALSE); if (arhPtr != NULL) { - modTimeTOC = (int) strtol(arhPtr->ar_date, NULL, 10); + modTimeTOC = (time_t)strtoq(arhPtr->ar_date, NULL, 10); if (DEBUG(ARCH) || DEBUG(MAKE)) { printf("%s modified %s...", RANLIBMAG, Targ_FmtTime(modTimeTOC)); Index: dir.c =================================================================== RCS file: /home/ncvs/src/usr.bin/make/dir.c,v retrieving revision 1.10.2.1 diff -u -r1.10.2.1 dir.c --- dir.c 2001/02/13 03:13:57 1.10.2.1 +++ dir.c 2001/10/28 00:33:12 @@ -858,7 +858,7 @@ } entry = Hash_CreateEntry(&mtimes, (char *) file, (Boolean *)NULL); - Hash_SetValue(entry, (long)stb.st_mtime); + Hash_SetValue_Time(entry, stb.st_mtime); nearmisses += 1; return (file); } else { @@ -936,7 +936,7 @@ printf("Caching %s for %s\n", Targ_FmtTime(stb.st_mtime), name); } - Hash_SetValue(entry, (long)stb.st_mtime); + Hash_SetValue_Time(entry, stb.st_mtime); return (estrdup (name)); } else { if (DEBUG(DIR)) { @@ -962,7 +962,7 @@ * found one for it, the full name is placed in the path slot. *----------------------------------------------------------------------- */ -int +time_t Dir_MTime (gn) GNode *gn; /* the file whose modification time is * desired */ @@ -992,9 +992,9 @@ */ if (DEBUG(DIR)) { printf("Using cached time %s for %s\n", - Targ_FmtTime((time_t)(long)Hash_GetValue(entry)), fullName); + Targ_FmtTime(Hash_GetValue_Time(entry)), fullName); } - stb.st_mtime = (time_t)(long)Hash_GetValue(entry); + stb.st_mtime = Hash_GetValue_Time(entry); Hash_DeleteEntry(&mtimes, entry); } else if (stat (fullName, &stb) < 0) { if (gn->type & OP_MEMBER) { Index: dir.h =================================================================== RCS file: /home/ncvs/src/usr.bin/make/dir.h,v retrieving revision 1.7 diff -u -r1.7 dir.h --- dir.h 1999/08/28 01:03:29 1.7 +++ dir.h 2001/10/28 00:33:26 @@ -58,7 +58,7 @@ Boolean Dir_HasWildcards __P((char *)); void Dir_Expand __P((char *, Lst, Lst)); char *Dir_FindFile __P((char *, Lst)); -int Dir_MTime __P((GNode *)); +time_t Dir_MTime __P((GNode *)); void Dir_AddDir __P((Lst, char *)); char *Dir_MakeFlags __P((char *, Lst)); void Dir_ClearPath __P((Lst)); Index: hash.c =================================================================== RCS file: /home/ncvs/src/usr.bin/make/hash.c,v retrieving revision 1.9 diff -u -r1.9 hash.c --- hash.c 1999/09/11 13:08:01 1.9 +++ hash.c 2001/10/28 00:29:55 @@ -250,7 +250,7 @@ hp = &t->bucketPtr[h & t->mask]; e->next = *hp; *hp = e; - e->clientData = NULL; + bzero(&e->u, sizeof(e->u)); e->namehash = h; (void) strcpy(e->name, p); t->numEntries++; Index: hash.h =================================================================== RCS file: /home/ncvs/src/usr.bin/make/hash.h,v retrieving revision 1.8 diff -u -r1.8 hash.h --- hash.h 1999/08/28 01:03:30 1.8 +++ hash.h 2001/10/28 00:27:43 @@ -56,8 +56,11 @@ struct Hash_Entry *next; /* Used to link together all the * entries associated with the same * bucket. */ - ClientData clientData; /* Arbitrary piece of data associated + union { + ClientData clientData; /* Arbitrary piece of data associated * with key. */ + time_t timeData; /* type agnostic time_t */ + } u; unsigned namehash; /* hash value of key */ char name[1]; /* key string */ } Hash_Entry; @@ -90,7 +93,8 @@ * Hash_Entry *h; */ -#define Hash_GetValue(h) ((h)->clientData) +#define Hash_GetValue(h) ((h)->u.clientData) +#define Hash_GetValue_Time(h) ((h)->u.timeData) /* * Hash_SetValue(h, val); @@ -98,7 +102,8 @@ * char *val; */ -#define Hash_SetValue(h, val) ((h)->clientData = (ClientData) (val)) +#define Hash_SetValue(h, val) ((h)->u.clientData = (ClientData) (val)) +#define Hash_SetValue_Time(h, val) ((h)->u.timeData = (val)) /* * Hash_Size(n) returns the number of words in an object of n bytes Index: make.h =================================================================== RCS file: /home/ncvs/src/usr.bin/make/make.h,v retrieving revision 1.12.2.2 diff -u -r1.12.2.2 make.h --- make.h 2001/02/13 03:13:58 1.12.2.2 +++ make.h 2001/10/28 00:31:05 @@ -144,8 +144,8 @@ * made */ int unmade; /* The number of unmade children */ - int mtime; /* Its modification time */ - int cmtime; /* The modification time of its youngest + time_t mtime; /* Its modification time */ + time_t cmtime; /* The modification time of its youngest * child */ Lst iParents; /* Links to parents for which this is an Index: nonints.h =================================================================== RCS file: /home/ncvs/src/usr.bin/make/nonints.h,v retrieving revision 1.8 diff -u -r1.8 nonints.h --- nonints.h 1999/08/28 01:03:35 1.8 +++ nonints.h 2001/10/28 00:48:33 @@ -43,8 +43,8 @@ ReturnStatus Arch_ParseArchive __P((char **, Lst, GNode *)); void Arch_Touch __P((GNode *)); void Arch_TouchLib __P((GNode *)); -int Arch_MTime __P((GNode *)); -int Arch_MemMTime __P((GNode *)); +time_t Arch_MTime __P((GNode *)); +time_t Arch_MemMTime __P((GNode *)); void Arch_FindLib __P((GNode *, Lst)); Boolean Arch_LibOODate __P((GNode *)); void Arch_Init __P((void)); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 19:43: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1534137B401 for ; Sat, 27 Oct 2001 19:42:59 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9S2gsX93100; Sat, 27 Oct 2001 22:42:54 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 22:42:54 -0400 (EDT) From: Garrett Wollman Message-Id: <200110280242.f9S2gsX93100@khavrinen.lcs.mit.edu> To: drosih@rpi.edu Subject: Re: time_t not to change size on x86, votes In-Reply-To: References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org 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 In article you write: >So much has been said in this thread, and so many suggestions >offered, that I am not sure anyone could reliably say where >people's votes are. Well, I think it's pretty clear where I stand, but your framework is a good one. > 1 = "I will fight against this change with all the keys on > my keyboard", > 3 = "I am basically neutral on the idea", and > 5 = "I am certain that the freebsd project should make this > change". > a) For the up-and-coming 64-bit platforms (sparc64, IA-64), > FreeBSD 5.0-release should have a 64-bit value for time_t. 5 > b) For the up-and-coming 32-bit platforms (PowerPC), > FreeBSD 5.0-release should have a 64-bit value for time_t. 3 > c) For the existing 32-bit platform (i386), > FreeBSD 5.0-release should have a 64-bit value. -Inf > d) For all 32-bit platforms (PowerPC, i386), > iff FreeBSD 5.0-release continues to be a 32-bit value, > then it should be called 'long' instead of 'int'. 2 (I don't feel very strongly, but I am mildly opposed to doing this. I believe, and have stated before, that it would be better to have some platforms be different, precisely to flush out unwarranted assumptions about the type underlying a time_t.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 19:57: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4F61337B406 for ; Sat, 27 Oct 2001 19:56:58 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9S2utu93282; Sat, 27 Oct 2001 22:56:55 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 22:56:55 -0400 (EDT) From: Garrett Wollman Message-Id: <200110280256.f9S2utu93282@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 In-Reply-To: <200110272220.f9RMKmH64657@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> <200110272220.f9RMKmH64657@apollo.backplane.com> 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 < said: > I already responded to the C90 stuff you posted. Your reasoning > and the elements you posted were extremely weak arguments, frankly. As opposed to you who has never participated in the standards process? > So frankly, Garrett, I don't really give a damn what a ten-year old > standard says. And I don't care whether you care or not, Matt. It doesn't make your proposal anything less than monumental stupidity. It took the original Standard C a good FIVE YEARS to be fully accepted, and we are still making concessions to pre-Standard C even today. It will take at least as much time for C99 to be as widespread. > 64 bit integer types on 32 bit platforms are totally acceptable > today. I never said they weren't. I said that we should not break old conforming Standard C applications. We have never been fully POSIX compliant -- the old POSIX was just too limited -- but we at least made an effort to support C90. You are proposing to break them, in order to facilitate programs which were using time_t incorrectly anyway. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 20:10:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D5A2E37B406 for ; Sat, 27 Oct 2001 20:10:34 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9S3AX088632; Sat, 27 Oct 2001 20:10:33 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 20:10:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200110280310.f9S3AX088632@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> <200110272220.f9RMKmH64657@apollo.backplane.com> <200110280256.f9S2utu93282@khavrinen.lcs.mit.edu> 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 : :< said: : :> I already responded to the C90 stuff you posted. Your reasoning :> and the elements you posted were extremely weak arguments, frankly. : :As opposed to you who has never participated in the standards process? What kind of idiotic statement is this? So only 'blessed' people have a right to have an opinion about something? Oh please. Your statement makes no sense at all, Garrett. Participation in this particular standard is not a prerequisit for having a worthwhile opinion on a section of it. The simple fact is that the C90 element you pointed was an extremely indirect and weak argument, and also quite out of date considering the fact that 64 bit ints on 32 bit architectures were not in common use 10 years ago. BSD actually spearheaded that with off_t. :> So frankly, Garrett, I don't really give a damn what a ten-year old :> standard says. : :And I don't care whether you care or not, Matt. It doesn't make your :proposal anything less than monumental stupidity. It took the :original Standard C a good FIVE YEARS to be fully accepted, and we are :still making concessions to pre-Standard C even today. It will take :at least as much time for C99 to be as widespread. So let me get this straight... you are saying there is a new standard out there that might allow this, but we shouldn't do anything that might conform to it that might break some other standard that is over a decade old? You are saying we shouldn't even begin adding C99 functionality for another 3 years? That makes no sense. These standards are based on what people are doing in the field... demonstarted functionality, but you are saying that we aren't allowed to demonstrate functionality for even the current 'new' standard by fixing an obviously flawed type? Again, such a position makes no sense. :> 64 bit integer types on 32 bit platforms are totally acceptable :> today. : :I never said they weren't. I said that we should not break old :conforming Standard C applications. We have never been fully POSIX :compliant -- the old POSIX was just too limited -- but we at least :made an effort to support C90. You are proposing to break them, in :order to facilitate programs which were using time_t incorrectly :anyway. : :-GAWollman I certainly am not proposing that we break them. The vast majority of programs will still work just fine, though without some hacking they may still fall when time overflows a 32 bit int (which they would have anyway). If you are going to argue that changing time_t to a 64 bit int 'breaks' all these alleged programs, then I recommend that you put your money where your mouth is and demonstrate this assumption. Because so far nearly all the code I've gone through either (A) just works with time_t as a 64 bit int, or (B) works with time_t as a 64 bit int but truncates it to 32 bits, leaving them no worse off then they were before. The two pieces of code I've come across that are 'broken' in the real sense of the word were assuming that sizeof(time_t) == sizeof(int) (not even long!), which is broken even under C90. So, Garrett, put your money where your mouth is. You seem to believe that this change will create all sorts of havoc. Prove it, because I am looking all code some of which is over 15 years old and I don't see it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 20:16:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 053A937B403; Sat, 27 Oct 2001 20:16:43 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9S3TTv21877; Sat, 27 Oct 2001 20:29:29 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110280329.f9S3TTv21877@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@freebsd.org Cc: Mike Smith Subject: Re: time_t not to change size on x86 In-reply-to: Your message of "Sat, 27 Oct 2001 00:50:30 PDT." <20011027005030.D94651@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Oct 2001 20:29:29 -0700 From: Mike Smith 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 > > Just to clarify, based on Peter's last mail. > > > > The proposal is not to change the size of time_t on x86, merely to > > select a suitable size on new platforms so that we migrate in a > > suitable fashion. > > What you describe is his *revamped* proposal. As one of the 3 in a > private thread that started this, I speak with greater knowledge on what > the proposal was. This isn't how Peter put it to me. And I stand by both his assessment of the situation, and his unwillingness to fight the issue beyond the reasonable. If you're foolish enough to try to pull this off, I'd much rather just let you all rot. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 20:32:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 6142A37B403; Sat, 27 Oct 2001 20:32:32 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9S3jGv22054; Sat, 27 Oct 2001 20:45:17 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110280345.f9S3jGv22054@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matthew Dillon Cc: Peter Wemm , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-reply-to: Your message of "Sat, 27 Oct 2001 13:14:46 PDT." <200110272014.f9RKEkj56354@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Oct 2001 20:45:16 -0700 From: Mike Smith 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 > And I'm sure there are still K&R problems too. The point is that > off_t being 64 bits has not posed a serious problem in at least 5 years, > probably longer. It's completely off the radar screen. Bollocks. I've had to deal with off_t problems in several major commercial porting efforts within the last couple of years, and I'm not even a major player in that arena. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 20:36:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 2B2E837B405 for ; Sat, 27 Oct 2001 20:36:20 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9S3n6v22087; Sat, 27 Oct 2001 20:49:06 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110280349.f9S3n6v22087@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matthew Dillon Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Sat, 27 Oct 2001 17:36:53 PDT." <200110280036.f9S0arb89926@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Oct 2001 20:49:06 -0700 From: Mike Smith 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 > So far it's been amazingly painless. I really don't think this is going > to be as big a deal as some people think (or even as big a deal as I > thought it would be, I'm already half way there!). The next step for > me is to write the syscall roll functions and test a 64 bit time_t > kernel with a 32 bit time_t userland. Please write a library routine that detects and compensates for: int t; time(&t); Until you can do this, sorry, no. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 21: 4: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3CF5337B401; Sat, 27 Oct 2001 21:03:58 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9S43vm88827; Sat, 27 Oct 2001 21:03:57 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 21:03:57 -0700 (PDT) From: Matthew Dillon Message-Id: <200110280403.f9S43vm88827@apollo.backplane.com> To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110280349.f9S3n6v22087@mass.dis.org> 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 : :> So far it's been amazingly painless. I really don't think this is going :> to be as big a deal as some people think (or even as big a deal as I :> thought it would be, I'm already half way there!). The next step for :> me is to write the syscall roll functions and test a 64 bit time_t :> kernel with a 32 bit time_t userland. : :Please write a library routine that detects and compensates for: : : : int t; : : time(&t); : :Until you can do this, sorry, no. Sorry, your statement makes no sense. Besides, if the programmer includes time.h the above will generate compiler warnings, so that's actually the easiest case to catch. I'll tell you what, why don't YOU write a library routine that detects this: /* no includes */ int x; lseek(fd, x, 0); Oops! That doesn't work either! Are you going to change our off_t from 64 back to 32 bits? No? Well, then I'm afraid you are going to have to just live with it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 21: 7:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 046FC37B401; Sat, 27 Oct 2001 21:07:11 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9S47A188852; Sat, 27 Oct 2001 21:07:10 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 21:07:10 -0700 (PDT) From: Matthew Dillon Message-Id: <200110280407.f9S47A188852@apollo.backplane.com> To: Mike Smith Cc: Peter Wemm , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <200110280345.f9S3jGv22054@mass.dis.org> 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 : :> And I'm sure there are still K&R problems too. The point is that :> off_t being 64 bits has not posed a serious problem in at least 5 years, :> probably longer. It's completely off the radar screen. : :Bollocks. I've had to deal with off_t problems in several major :commercial porting efforts within the last couple of years, and I'm not :even a major player in that arena. Well boohoo, I'm sure it was a real nasty, difficult problem for you. That seems to be what you are implying. It must have been *real* hard doing a #include ! Me? It took me all of 10 seconds to fix the off_t bugs when they came up. I minded a little at first, but it wasn't long until I became a believer. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 27 23:39: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1BBD137B401 for ; Sat, 27 Oct 2001 23:38:57 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9S6cuA99947; Sat, 27 Oct 2001 23:38:56 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 23:38:56 -0700 (PDT) From: Matthew Dillon Message-Id: <200110280638.f9S6cuA99947@apollo.backplane.com> To: arch@FreeBSD.ORG Subject: illegal &time_t useage in /usr/src 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 I found 14 instances of illegal time_t casts. They all look very easy to fix. Most are protocol-related so the correct solution is truncation. About half assume sizeof(time_t) == sizeof(int). The other half assume sizeof(time_t) == sizeof(long). I think a couple even assume sizeof(time_t) == sizeof(int32_t). I found about a hundred instances of non-fatal time_t truncation (i.e. program works fine with 64 bit time_t's but will blow up after 2038 (would blow up anyway if not fixed by 2038 no matter what the platform)). named alone is very amusing code... it squeaks in and appears to produce runnable (truncation mode) code, but boy is it a hodge podge of useages. All told I found numerous instances where time_t was assumed to be exactly equivalent to ... int, long, ulong, int32_t, void *, etc... but only 14 where pass-by-reference cast overrides produced broken code. All the problem areas are minor and can be fixed in a few minutes. Most of the protocols could even be upgraded (instead of truncating), though I see no particular reason to create the incompatibility just now. The elf and a.out timestamps would have to be left in truncated mode for obvious reasons. Some of the newer cpio protocols are already good for 11 digits and I've comitted those changes, as well as some other minor fixups. The next step is for me to do the syscall roll, test with 32 bit binaries, then do a full 64 bit buildworld and test a full 64 bit time_t system. Patches will probably be available for wider testing next week sometime. I'll also get in touch with the contrib owners in regards to their time_t issues. Most of these bugs are bugs that have to be fixed for 64 bit platforms and/or for 64 bit platforms / 64 bit time_t anyway. I won't actually commit any IA32/64-bit time_t changes for at least another month, assuming I can push that part of it through. -Matt ./contrib/binutils/bfd/elf32-mips.c: unmodified: line 8584 of 9049 [94%] ./contrib/gcc/mips-tdump.c: unmodified: line 776 of 1606 [48%] ./contrib/ipfilter/ipmon.c: unmodified: line 496 of 1282 [38%] ./contrib/ipfilter/ipmon.c: unmodified: line 717 of 1282 [55%] ./contrib/gcc.295/mips-tdump.c: unmodified: line 776 of 1606 [48%] ./crypto/heimdal/appl/dceutils/k5dcecon.c: unmodified: line 186 of 791 [23%] (krb5_timestamp is a krb5_int32) ./sbin/dump/main.c: unmodified: line 110 of 652 [16%] /usr/include/protocols/dumprestore.h (dump header embeds time_t directly, size changes. Not an error but should probably be converted to truncated form to maintain backwards dump compatibility) ./sbin/ipfw/ipfw.c: unmodified: line 206 of 2617 [7%] ./sbin/ip6fw/ip6fw.c: unmodified: line 211 of 1407 [14%] ./usr.bin/rusers/rusers.c: unmodified: line 119 of 245 [48%] (not an error, but size of utmp structure changes) ./usr.bin/rwho/rwho.c: unmodified: line 168 of 221 [76%] /usr/include/protocols/rwhod.h out_time is int32_t, rwho assumes it is == time_t, which is completely illegal. ./usr.sbin/rwhod/rwhod.c: unmodified: line 328 of 745 [44%] /usr/include/protocols/rwhod.h wd_recvtime declared as int, assumed to be equiv to time_t, which is completely illegal. ./usr.sbin/tcpdump/tcpslice/tcpslice.c: unmodified: line 203 of 621 [32%] ./usr.sbin/yppoll/yppoll.c: unmodified: line 91 of 98 [92%] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message