From owner-freebsd-arch Sun Oct 28 1:26:52 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 333D137B403 for ; Sun, 28 Oct 2001 01:26:49 -0800 (PST) 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 <20011028092326.WNBZ2039.amsfep16-int.chello.nl@daemon.chronias.ninth-circle.org>; Sun, 28 Oct 2001 10:23:26 +0100 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f9S9QN126428; Sun, 28 Oct 2001 10:26:23 +0100 (CET) (envelope-from asmodai) Date: Sun, 28 Oct 2001 10:26:23 +0100 From: Jeroen Ruigrok/Asmodai To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src Message-ID: <20011028102623.X96876@daemon.ninth-circle.org> References: <200110280638.f9S6cuA99947@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110280638.f9S6cuA99947@apollo.backplane.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 [20011028 08:00], Matthew Dillon (dillon@apollo.backplane.com) wrote: >./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) Any chance of committing this script to src/tools? -- 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/ Only the good die young, all the evil seems to live forever... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 2:35:19 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 2BF2C37B401 for ; Sun, 28 Oct 2001 02:35:15 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id f9SAZAu59311; Sun, 28 Oct 2001 11:35:11 +0100 (CET) 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 f9SAZPSe042430; Sun, 28 Oct 2001 11:35:26 +0100 (CET)?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 f9SAZ8F11475; Sun, 28 Oct 2001 11:35:08 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id f9SAZBS49135; Sun, 28 Oct 2001 11:35:11 +0100 (CET) (envelope-from ticso) Date: Sun, 28 Oct 2001 11:35:09 +0100 From: Bernd Walter To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src Message-ID: <20011028113509.A48670@cicely8.cicely.de> References: <200110280638.f9S6cuA99947@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110280638.f9S6cuA99947@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 Sat, Oct 27, 2001 at 11:38:56PM -0700, Matthew Dillon wrote: > 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. That's good to hear. But so far the discussion went completely to time_t only. What about struct timespec and struct timeval? There is no functional need to have long defined tv_nsec and tv_usec fields as long as no spec says so. The tv_sec field on struct timeval would still be 32 bit on 32 bit platforms. What about sub nsec representations? -- 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 Sun Oct 28 3:12:55 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 1D74237B401; Sun, 28 Oct 2001 03:12:49 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9SBPNv26553; Sun, 28 Oct 2001 03:25:35 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200110281125.f9SBPNv26553@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matthew Dillon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Sat, 27 Oct 2001 21:03:57 PDT." <200110280403.f9S43vm88827@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Oct 2001 03:25:23 -0800 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 > : > :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. I'm sorry you can't parse this; it's a simplified version of Garrett's perfectly valid point that prototypes won't save you from pass-by-reference, which is a major problem here. > Besides, if the programmer > includes time.h the above will generate compiler warnings, so > that's actually the easiest case to catch. You (mistakenly) assume that the programmer is going to be looking at these warnings, let alone enable them in the first place. The above code has worked for decades, why should it change now? > 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. The two cases aren't comparable. The first is typically written int t; time((time_t *)&t); to shut the compiler up in the first place, and even with a prototype for time() in scope, will still generate broken code. Again I say; you are introducing a gratuitous and evil change to satisfy a vested minority interest. Though I don't know why I bother trying to convince you, since you're not in a position to recognise this anyway. -- ... 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 28 3:43:39 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 47B2A37B403 for ; Sun, 28 Oct 2001 03:43:34 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9SBgsS33644; Sun, 28 Oct 2001 12:42:54 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bernd Walter Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src In-Reply-To: Your message of "Sun, 28 Oct 2001 11:35:09 +0100." <20011028113509.A48670@cicely8.cicely.de> Date: Sun, 28 Oct 2001 12:42:54 +0100 Message-ID: <33642.1004269374@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 <20011028113509.A48670@cicely8.cicely.de>, Bernd Walter writes: >On Sat, Oct 27, 2001 at 11:38:56PM -0700, Matthew Dillon wrote: >But so far the discussion went completely to time_t only. >What about struct timespec and struct timeval? We can't get rid of those, they API used. >There is no functional need to have long defined tv_nsec and tv_usec >fields as long as no spec says so. Right, I don't think anybody actually insisted on that. >The tv_sec field on struct timeval would still be 32 bit on 32 bit >platforms. You lost me there, I don't think that is mandated. >What about sub nsec representations? I'll deal with that, I wrote our timecounter code and I know what needs done. -- 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 Sun Oct 28 5:11:19 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 1FE1637B401 for ; Sun, 28 Oct 2001 05:11:13 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id f9SDB7d60963; Sun, 28 Oct 2001 14:11:07 +0100 (CET) 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 f9SD6bSe043726; Sun, 28 Oct 2001 14:06:38 +0100 (CET)?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 f9SD6JF11644; Sun, 28 Oct 2001 14:06:19 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id f9SD6Ju49881; Sun, 28 Oct 2001 14:06:19 +0100 (CET) (envelope-from ticso) Date: Sun, 28 Oct 2001 14:06:18 +0100 From: Bernd Walter To: Poul-Henning Kamp Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src Message-ID: <20011028140618.A49388@cicely8.cicely.de> References: <20011028113509.A48670@cicely8.cicely.de> <33642.1004269374@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33642.1004269374@critter.freebsd.dk> 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 Sun, Oct 28, 2001 at 12:42:54PM +0100, Poul-Henning Kamp wrote: > In message <20011028113509.A48670@cicely8.cicely.de>, Bernd Walter writes: > >On Sat, Oct 27, 2001 at 11:38:56PM -0700, Matthew Dillon wrote: > > >But so far the discussion went completely to time_t only. > >What about struct timespec and struct timeval? > > We can't get rid of those, they API used. But still part of the original question. > >There is no functional need to have long defined tv_nsec and tv_usec > >fields as long as no spec says so. > > Right, I don't think anybody actually insisted on that. If time_t changes it's size struct timespec changes too. Why not correcting struct timespec.tv_nsec to int32_t in one turn? > >The tv_sec field on struct timeval would still be 32 bit on 32 bit > >platforms. > > You lost me there, I don't think that is mandated. Not mandated. It's simply part of the getting over 2038 thing. That said - I don't know which fields are forced to be long by standarts. -- 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 Sun Oct 28 7:33:36 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 7B88237B405 for ; Sun, 28 Oct 2001 07:33:33 -0800 (PST) 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 CAA02802; Mon, 29 Oct 2001 02:33:19 +1100 Date: Mon, 29 Oct 2001 02:32:20 +1100 (EST) From: Bruce Evans X-X-Sender: To: Bernd Walter Cc: Matthew Dillon , Subject: Re: illegal &time_t useage in /usr/src In-Reply-To: <20011028113509.A48670@cicely8.cicely.de> Message-ID: <20011029022409.P3648-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 Sun, 28 Oct 2001, Bernd Walter wrote: > What about struct timespec and struct timeval? > There is no functional need to have long defined tv_nsec and tv_usec > fields as long as no spec says so. Specs do say so. timespec is { time_t tv_sec; long tv_nsec; } (POSIX.1-1996). timeval is { time_t tv_sec; suseconds_t tv_usec; } (draft POSIX.1-200x). suseconds_t is a signed integer type capable of storing values at least in the range [-1, 1000000]. So you can change the type of tv_usec (but shouldn't, because it is specified to be long by old defacto standards), but you can't change tv_nsec (and neither can standards, because it is specified to be long by old standards). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 8:23: 2 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 2C0B137B42A for ; Sun, 28 Oct 2001 08:22:47 -0800 (PST) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.6/8.11.6) with ESMTP id f9SGMgZ71251; Sun, 28 Oct 2001 09:22:42 -0700 (MST) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200110281622.f9SGMgZ71251@hunkular.glarp.com> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: need review make time_t type agnostic changes In-Reply-To: Your message of "Sat, 27 Oct 2001 17:55:35 PDT." <200110280055.f9S0tZ184290@apollo.backplane.com> Date: Sun, 28 Oct 2001 09:22:42 -0700 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 > 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. I know this is obvious, but while your at it, could you define a preprocessor flag such as -D__USE_OLD_TIME_T=1 for non-kernel apps? I doubt it's worth the trouble to have two such flags __USE_INT_TIME_T versus __USE_LONG_TIME_T, so I would vote for only one backward compatibility flag which exactly reproduces the old behavior (int). If the consensus is that this should _not_ debut in 5.0, then we could do something like #if !defined(__USE_OLD_TIME_T) && !defined(__USE_NEW_TIME_T) #define __USE_OLD_TIME_T #endif #ifdef __USE_OLD_TIME_T typedef time_t int; #else typedef time_t int64_t; #endif which would allow people to easily test the new 64bit time_t. brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 9: 1:47 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 61DB637B405 for ; Sun, 28 Oct 2001 09:01:44 -0800 (PST) Received: (qmail 93309 invoked from network); 28 Oct 2001 17:01:38 -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 ; 28 Oct 2001 17:01:38 -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: <200110271655.f9RGtX947498@apollo.backplane.com> Date: Sun, 28 Oct 2001 09:01:35 -0700 (PST) From: John Baldwin To: Matthew Dillon Subject: Re: 64 bit times revisited.. Cc: Garrett Wollman , des@ofug.org, 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 27-Oct-01 Matthew Dillon wrote: >: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. I'll leave that to the language lawyers. > 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. Err, what about software written in 1998? It didnt' have C99, so it would conform to C90. You want to break 3 year old software? You can't just depend on the newest standard. People have to have time to migrate code that depended on things in the old standard that aren't supported in the newest. If there were a C95 or C96 or something, then it would probably make sense to switch our baseline to that, but AFAIK there isn't and all we have is C90 and C99. (Someone jump in here if I'm mistaken.) IMO, C99 is too recent to mandate as our baseline, so we are left with C90. It may be old, but it was the definitive standard 3 years ago. > -Matt > Matthew Dillon > -- 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 Sun Oct 28 9:17:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id D97EE37B403 for ; Sun, 28 Oct 2001 09:17:47 -0800 (PST) Received: from dialup-209.245.128.59.dial1.sanjose1.level3.net ([209.245.128.59] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xtZ6-00013A-00; Sun, 28 Oct 2001 09:17:40 -0800 Message-ID: <3BDC3DE6.9F282BC@mindspring.com> Date: Sun, 28 Oct 2001 09:18:30 -0800 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: Garrett Wollman , 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> 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: > :> If time_t can be a double, it damn > :> well can be an int64_t. > : > :No, it can't. RTFS. > > 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. Garrett is right. In laymans terms, the standard says that time_t must be of a type that will result in atomic update during assignment, and that this type must be a standard defined type (which lets out the "long long" type). I have had technical and philosophical disagreements with Garrett before, but I can count the number of times I was right and he was wrong about a standard on the fingers of one hand. You do realize -- he's _on_ the committees, right? The _only_ way you could get around this and remain in conformance with C90 would be to change "long" to be 64 bits; C99 is another language, altogether; it's still not clear to me that "long long" will end up being an atomic type on all platforms; I expect that on an 80386 (as opposed to a Pentium), "long long" will be 32 bits, just like "int" and "long", or you still won't be allowed to use it for time_t. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 9:19:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 3665037B406 for ; Sun, 28 Oct 2001 09:19:26 -0800 (PST) Received: from dialup-209.245.128.59.dial1.sanjose1.level3.net ([209.245.128.59] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xtam-0002MH-00; Sun, 28 Oct 2001 09:19:25 -0800 Message-ID: <3BDC3E4F.A8C0A3F3@mindspring.com> Date: Sun, 28 Oct 2001 09:20:15 -0800 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: Garrett Wollman , 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> 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: > 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? The requirements for time_t are different than those for off_t, which is not even noted at all by C90. I personally don't know what C99 says, but that's OK, since you can't get a compiler for it anyway. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 9:20:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 4F88F37B405; Sun, 28 Oct 2001 09:20:32 -0800 (PST) Received: from dialup-209.245.128.59.dial1.sanjose1.level3.net ([209.245.128.59] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xtbi-000345-00; Sun, 28 Oct 2001 09:20:23 -0800 Message-ID: <3BDC3E88.D684676F@mindspring.com> Date: Sun, 28 Oct 2001 09:21:12 -0800 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: Jordan Hubbard Cc: Poul-Henning Kamp , Peter Wemm , Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <43093.1004217988@winston.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 Jordan Hubbard wrote: > > > 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. Any tool looks evil if it is used incorrectly. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 10: 9:39 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 F3EC637B406 for ; Sun, 28 Oct 2001 10:09:36 -0800 (PST) Received: from dialup-209.245.128.59.dial1.sanjose1.level3.net ([209.245.128.59] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15xuN5-0001Hd-00; Sun, 28 Oct 2001 10:09:20 -0800 Message-ID: <3BDC4A01.B910ECCC@mindspring.com> Date: Sun, 28 Oct 2001 10:10:09 -0800 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: drosih@rpi.edu, arch@FreeBSD.org Subject: Re: time_t not to change size on x86, votes References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net> <200110280242.f9S2gsX93100@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: > > 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.) I agree, as long as it's not the x86 platform that different. FreeBSD has most of its effort concentrated on the x86, and so hobbling the Alpha or some other currently marginally supported platform to get this shakeout would be a bad idea. I suggested before being able to turn on the alignmnet bit on x86 to shakeout alignment bugs... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 10:14:41 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 EA7F537B407 for ; Sun, 28 Oct 2001 10:14:35 -0800 (PST) Received: from dialup-209.245.128.59.dial1.sanjose1.level3.net ([209.245.128.59] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15xuSA-00057W-00; Sun, 28 Oct 2001 10:14:34 -0800 Message-ID: <3BDC4B3C.1E6A431E@mindspring.com> Date: Sun, 28 Oct 2001 10:15:24 -0800 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: Garrett Wollman , 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> <200110280310.f9S3AX088632@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: > :> 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. I agree... now when does Linus get his commit bits, so it's not only blessed people who have a right to an opinion about what the FreeBSD source code should be? 8-) 8-). Seriously, the "blessing" in this case is that he's had to sit through interminable meetings where, at least in theory, all of the issues raised by the changes being proposed have been discussed by people with contradictory opinions, and have then reached at least a rough consensus, or the decision to leave the behaviour undefined (an agreement to disagree). If you want to pare it down to the nub, the issue is sign extension to the largest type on the stack, in the absence of prototypes... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 10:17:31 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 CB77637B405; Sun, 28 Oct 2001 10:17:28 -0800 (PST) Received: from dialup-209.245.128.59.dial1.sanjose1.level3.net ([209.245.128.59] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15xuUx-0007FZ-00; Sun, 28 Oct 2001 10:17:28 -0800 Message-ID: <3BDC4BEA.520DB04D@mindspring.com> Date: Sun, 28 Oct 2001 10:18:18 -0800 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: Mike Smith , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110280349.f9S3n6v22087@mass.dis.org> <200110280403.f9S43vm88827@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: > 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. The off_t is not covered by the C standard, only by POSIX. But even so... All I have to do is define stack passing in the absence of a prototype to result in a sign extension to 64 bits. This is a fairly minor tweak to the compiler sources. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 10:27:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from raven.mail.pas.earthlink.net (raven.mail.pas.earthlink.net [207.217.120.39]) by hub.freebsd.org (Postfix) with ESMTP id F18D237B405; Sun, 28 Oct 2001 10:27:48 -0800 (PST) Received: from dialup-209.245.128.59.dial1.sanjose1.level3.net ([209.245.128.59] helo=mindspring.com) by raven.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15xuey-0002Ah-00; Sun, 28 Oct 2001 10:27:48 -0800 Message-ID: <3BDC4E53.B823C1BF@mindspring.com> Date: Sun, 28 Oct 2001 10:28:35 -0800 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: Mike Smith Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110281125.f9SBPNv26553@mass.dis.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 Mike Smith wrote: > You (mistakenly) assume that the programmer is going to be looking at these > warnings, let alone enable them in the first place. The above code has > worked for decades, why should it change now? The same reason the "volatile fairy" had to go sprinkling the word "volatile" over code that worked for decades so that it wouldn't break the next time it was compiled because of some bogus assumption about the safety of promoting something to a register being the programmer's job instead of the compiler writer's job, what with compiler writers outnumbering the programmers (NOT!), and all? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 11:23:55 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 468E537B401 for ; Sun, 28 Oct 2001 11:23:53 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9SJNpI06845; Sun, 28 Oct 2001 11:23:51 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Oct 2001 11:23:51 -0800 (PST) From: Matthew Dillon Message-Id: <200110281923.f9SJNpI06845@apollo.backplane.com> To: Jeroen Ruigrok/Asmodai Cc: arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src References: <200110280638.f9S6cuA99947@apollo.backplane.com> <20011028102623.X96876@daemon.ninth-circle.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 [20011028 08:00], Matthew Dillon (dillon@apollo.backplane.com) wrote: :>./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) : :Any chance of committing this script to src/tools? : :-- :Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Kinda hard to commit a human being :-) Something like the below, reidrect the output to a file and then go vi `cat filename` and run through the cases manually. #!/bin/tcsh # # (expected to be in /usr/src) foreach i ( `find . -type f -name "*.c" -or -name "*.h"` ) fgrep '(time_t *)' $i >& /dev/null if ( $status == 0 ) then echo $i endif end Repeat for instances of 'localtime', 'ctime', and 'time (' or 'time(' (for which there are hundreds). -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 Sun Oct 28 11:26:15 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 5FB1837B401; Sun, 28 Oct 2001 11:26:12 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9SJQCK13483; Sun, 28 Oct 2001 11:26:12 -0800 (PST) (envelope-from obrien) Date: Sun, 28 Oct 2001 11:26:11 -0800 From: "David O'Brien" To: "Bruce A. Mah" Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/contrib/one-true-awk - Imported sources Message-ID: <20011028112611.E92519@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20011028125507.A96876@daemon.ninth-circle.org> <20011029021401.O3597-100000@delplex.bde.org> <20011028103759.A92519@dragon.nuxi.com> <200110281913.f9SJDIY19505@c527597-a.cstvl1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110281913.f9SJDIY19505@c527597-a.cstvl1.sfba.home.com>; from bmah@FreeBSD.org on Sun, Oct 28, 2001 at 11:13:18AM -0800 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 Sun, Oct 28, 2001 at 11:13:18AM -0800, Bruce A. Mah wrote: > FYI: Per some discussion on -arch@ over licensing issues, I sent an > email to bwk on Friday requesting clarification (basically boiled down > to "is it allowed by the license to include the-one-true-awk in a > distribution that may be sold for profit?"). If it's OK with you, I'd The license is fine! We already have a lot of bits with this same license in our tree. NetBSD and OpenBSD both use the One True Awk. grep 'and without fee' /usr/include/*.h /usr/include/*/*.h > like to get a reply from him first before you flip the switch. There is no need. What do you find unclear about the license? -- -- 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 Sun Oct 28 11:36:21 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 59B7337B405; Sun, 28 Oct 2001 11:36:16 -0800 (PST) Received: (from bmah@localhost) by c527597-a.cstvl1.sfba.home.com (8.11.6/8.11.6) id f9SJaGh19709; Sun, 28 Oct 2001 11:36:16 -0800 (PST) (envelope-from bmah) Message-Id: <200110281936.f9SJaGh19709@c527597-a.cstvl1.sfba.home.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: obrien@FreeBSD.org Cc: "Bruce A. Mah" , arch@FreeBSD.org Subject: Re: cvs commit: src/contrib/one-true-awk - Imported sources In-Reply-To: <20011028112611.E92519@dragon.nuxi.com> References: <20011028125507.A96876@daemon.ninth-circle.org> <20011029021401.O3597-100000@delplex.bde.org> <20011028103759.A92519@dragon.nuxi.com> <200110281913.f9SJDIY19505@c527597-a.cstvl1.sfba.home.com> <20011028112611.E92519@dragon.nuxi.com> Comments: In-reply-to "David O'Brien" message dated "Sun, 28 Oct 2001 11:26:11 -0800." From: bmah@FreeBSD.org (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_350778160P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 28 Oct 2001 11:36:16 -0800 Sender: owner-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_350778160P Content-Type: text/plain; charset=us-ascii If memory serves me right, "David O'Brien" wrote: > On Sun, Oct 28, 2001 at 11:13:18AM -0800, Bruce A. Mah wrote: > > FYI: Per some discussion on -arch@ over licensing issues, I sent an > > email to bwk on Friday requesting clarification (basically boiled down > > to "is it allowed by the license to include the-one-true-awk in a > > distribution that may be sold for profit?"). If it's OK with you, I'd > > The license is fine! We already have a lot of bits with this same > license in our tree. NetBSD and OpenBSD both use the One True Awk. I admit I didn't know that other *BSDs use it, or that we have other license bits like this. > grep 'and without fee' /usr/include/*.h /usr/include/*/*.h > > > like to get a reply from him first before you flip the switch. > > There is no need. What do you find unclear about the license? Here's the part I'm unclear on. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted... Does "and without fee" apply to granting permission, or does it apply to using, copying, modifying, and distributing? In the first case, we're fine. In the second case, we might have a problem. I don't have any real objections otherwise, and in any case I'm not the person doing the work, so it's certainly not my place to say "you can't do this"..... Bruce. --==_Exmh_350778160P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE73F4w2MoxcVugUsMRAtL7AJ9Idmcy8AK0N7gMXWTaD1rS/L4aWgCg5plr klJFgrTlsMxKa7q0lEpk58w= =vwOq -----END PGP SIGNATURE----- --==_Exmh_350778160P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 12: 2:24 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 8152037B401 for ; Sun, 28 Oct 2001 12:02:19 -0800 (PST) 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 GAA24471; Mon, 29 Oct 2001 06:49:40 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01KA2BKB5NGWVMP4S3@cim.alcatel.com.au>; Mon, 29 Oct 2001 06:49:39 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9SJnbA90739; Mon, 29 Oct 2001 06:49:38 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 29 Oct 2001 06:49:37 +1100 From: Peter Jeremy Subject: Re: 64 bit times revisited.. In-reply-to: <200110260020.f9Q0KQR63759@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Oct 25, 2001 at 08:20:26PM -0400 To: Garrett Wollman Cc: arch@FreeBSD.ORG Mail-Followup-To: Garrett Wollman , arch@FreeBSD.ORG Message-id: <20011029064937.C75481@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: <20011025233602.587C63808@overcee.netplex.com.au> <200110260020.f9Q0KQR63759@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 On Thu, Oct 25, 2001 at 08:20:26PM -0400, Garrett Wollman wrote: >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. How many syscalls would this impact? My guess is that it would be a significant number. Also, this approach can easily lead to exponential growth in the number of syscalls: Consider a hypothetical system that has two off_t sizes and two time_t sizes - it will need 4 stat() syscalls (and maybe others). It's also relatively difficult to recover old syscalls. (A number of wrapper functions around a single syscall() would be more manageable). > On new platforms (regardless of native word size), use the 64-bit >versions. I agree about using a 64-bit time_t for new 64-bit (or larger) architectures. I'm less certain about using 64-bit time_t on any new 32-bit architectures - supporting double-width operation is usually fairly expensive. > Meanwhile, start deploying a new inode format with 64-bit times. This is a different bikeshed - we need to extend the inode timestamps at both ends - we need more resolution as well as more range. (The 1-second granularity has been a problem for a few years already). It's unclear how to easily achieve this (since C doesn't have native support for fixed-point binary types and bitfields are only supported for int (and shorter) types). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 12: 2: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 7073E37B401; Sun, 28 Oct 2001 12:02:28 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9SK2SS14172; Sun, 28 Oct 2001 12:02:28 -0800 (PST) (envelope-from obrien) Date: Sun, 28 Oct 2001 12:02:28 -0800 From: "David O'Brien" To: "Bruce A. Mah" Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/contrib/one-true-awk - Imported sources Message-ID: <20011028120228.B14028@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20011028125507.A96876@daemon.ninth-circle.org> <20011029021401.O3597-100000@delplex.bde.org> <20011028103759.A92519@dragon.nuxi.com> <200110281913.f9SJDIY19505@c527597-a.cstvl1.sfba.home.com> <20011028112611.E92519@dragon.nuxi.com> <200110281936.f9SJaGh19709@c527597-a.cstvl1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110281936.f9SJaGh19709@c527597-a.cstvl1.sfba.home.com>; from bmah@FreeBSD.org on Sun, Oct 28, 2001 at 11:36:16AM -0800 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 Sun, Oct 28, 2001 at 11:36:16AM -0800, Bruce A. Mah wrote: > Here's the part I'm unclear on. > > Permission to use, copy, modify, and distribute this software and > its documentation for any purpose and without fee is hereby > granted... > > Does "and without fee" apply to granting permission, It means we don't have to pay the copyright holder to "use, copy, modify, and distribute". -- -- 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 Sun Oct 28 16:31: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 380DD37B403 for ; Sun, 28 Oct 2001 16:31:55 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9T0VgZ32597; Sun, 28 Oct 2001 16:31:42 -0800 (PST) (envelope-from obrien) Date: Sun, 28 Oct 2001 16:31:41 -0800 From: "David O'Brien" To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src Message-ID: <20011028163141.A32015@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200110280638.f9S6cuA99947@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: <200110280638.f9S6cuA99947@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Oct 27, 2001 at 11:38:56PM -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 Sat, Oct 27, 2001 at 11:38:56PM -0700, Matthew Dillon wrote: > ./contrib/binutils/bfd/elf32-mips.c: unmodified: line 8584 of 9049 [94%] > ./contrib/gcc/mips-tdump.c: unmodified: line 776 of 1606 [48%] > ./contrib/gcc.295/mips-tdump.c: unmodified: line 776 of 1606 [48%] Don't worry about these -- we don't use the MIPS bits. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 16:36:11 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 1BE4137B401; Sun, 28 Oct 2001 16:35:54 -0800 (PST) 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 IAA03251; Mon, 29 Oct 2001 08:14:09 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01KA2EIUINDS2FELOH@cim.alcatel.com.au>; Mon, 29 Oct 2001 08:14:01 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9SLE1F91464; Mon, 29 Oct 2001 08:14:01 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 29 Oct 2001 08:14:01 +1100 From: Peter Jeremy Subject: Re: cvs commit: src/sbin/newfs newfs.8 newfs.c In-reply-to: <200110261630.f9QGTwa79290@aldan.algebra.com>; from mi@aldan.algebra.com on Fri, Oct 26, 2001 at 12:29:55PM -0400 To: Mikhail Teterin Cc: obrien@FreeBSD.org, cvs-committers@FreeBSD.org, freebsd-arch@FreeBSD.org Mail-Followup-To: Mikhail Teterin , obrien@FreeBSD.org, cvs-committers@FreeBSD.org, freebsd-arch@FreeBSD.org Message-id: <20011029081400.H75481@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: <20011026153413.Z75481@gsmx07.alcatel.com.au> <200110261630.f9QGTwa79290@aldan.algebra.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 2001-Oct-26 12:29:55 -0400, Mikhail Teterin wrote: >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? The following patch will make newfs default to 2 cylinder groups where a filesystem has 4 or more cylinders. (You probably don't want more than 1 CG on smaller filesystems). If this results in excessively large CPs, it will be reduced in mkfs(). For filesystems just over twice the maximum size of a cylinder group, having cpg = ncyls/3 would give a more even spread, but would require a more extensive change in mkfs(). It's obviously impractical for newfs to tweak the partition size to suit itself. Note: This patch is untested. It should apply to -stable as well, but the line numbers for the 2nd hunk are too far out for patch(1) to handle ("@@ -618,8 +622,14 @@" is the appropriate hunk header for -stable). When manually applied to -stable, newfs compiles. (My running -current is too out-of date to easily compile it). Index: newfs.c =================================================================== RCS file: /home/CVSROOT/src/sbin/newfs/newfs.c,v retrieving revision 1.42 diff -u -r1.42 newfs.c --- newfs.c 2001/10/04 12:24:18 1.42 +++ newfs.c 2001/10/28 20:52:29 @@ -102,12 +102,16 @@ #define DFL_BLKSIZE 8192 /* - * Cylinder groups may have up to many cylinders. The actual - * number used depends upon how much information can be stored - * on a single cylinder. The default is to use as many as possible - * cylinders per group. + * Cylinder groups comprise an integral number of cylinders. The + * actual number used depends upon how much information can be stored + * on a single cylinder. The default is to have a single group for + * filesystems smaller than TINYFS cylinders and MINCGS cylinder + * groups otherwise. The actual number of cylinder groups may be + * larger than MINCGS due to restrictions on the number of cylinders + * per group. */ -#define DESCPG 65536 /* desired fs_cpg ("infinity") */ +#define TINYFS 4 /* Default to 1 CG below this size */ +#define MINCGS 2 /* Default to this many cylinder groups */ /* * Once upon a time... @@ -548,8 +552,14 @@ ncyls = fssize / secpercyl; if (ncyls == 0) ncyls = 1; /* XXX */ - if (cpg == 0) - cpg = DESCPG < ncyls ? DESCPG : ncyls; + /* + * By default we try to create MINCGS cylinder groups. For + * tiny filesystems, this is impractical. On large filesystems, + * cpg will be further limited to the largest possible size + * (restricted by the blocks/inodes per group) within mkfs(). + */ + if (!cpgflg) + cpg = ncyls < TINYFS ? ncyls : (ncyls + MINCGS - 1) / MINCGS; else if (cpg > ncyls) { cpg = ncyls; printf( Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 16:38:36 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 9A45F37B409 for ; Sun, 28 Oct 2001 16:38:30 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9T0cQb57553; Sun, 28 Oct 2001 16:38:26 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Oct 2001 16:38:26 -0800 (PST) From: Matthew Dillon Message-Id: <200110290038.f9T0cQb57553@apollo.backplane.com> To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src References: <200110280638.f9S6cuA99947@apollo.backplane.com> <20011028163141.A32015@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 Sat, Oct 27, 2001 at 11:38:56PM -0700, Matthew Dillon wrote: :> ./contrib/binutils/bfd/elf32-mips.c: unmodified: line 8584 of 9049 [94%] :> ./contrib/gcc/mips-tdump.c: unmodified: line 776 of 1606 [48%] :> ./contrib/gcc.295/mips-tdump.c: unmodified: line 776 of 1606 [48%] : :Don't worry about these -- we don't use the MIPS bits. Oh good, because I wasn't sure what to do about those. This is what is left: ./contrib/ipfilter/ipmon.c: unmodified: line 496 of 1282 [38%] ./contrib/ipfilter/ipmon.c: unmodified: line 717 of 1282 [55%] ./crypto/heimdal/appl/dceutils/k5dcecon.c: unmodified: line 186 of 791 [23%] (krb5_timestamp is a krb5_int32) There are some new ones due to the recent ut_time structural change which I'm pounding away on. All minor. -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 Sun Oct 28 17:14: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 00AE737B406; Sun, 28 Oct 2001 17:14:22 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9T1EI133142; Sun, 28 Oct 2001 17:14:18 -0800 (PST) (envelope-from obrien) Date: Sun, 28 Oct 2001 17:14:18 -0800 From: "David O'Brien" To: Jim Pirzyk Cc: Marcel Moolenaar , Peter Wemm , Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <20011028171418.D32015@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net> <3BDB103F.763377D@disney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BDB103F.763377D@disney.com>; from Jim.Pirzyk@disney.com on Sat, Oct 27, 2001 at 12:51:28PM -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 Sat, Oct 27, 2001 at 12:51:28PM -0700, Jim Pirzyk wrote: > > I too agree that we should change time_t on the 64bit > > platforms and leave the i386 platform alone. Since people are resisting moving i386 to a 64-bit time_t, only the Alpha users should be able to vote what happens on their platform. Matt Dillon has found bugs where code assumed sizeof(time_t) == sizeof(int), which was benign on the i386, would have been deadly on the Alpha. And this is *precisely* why I have fought to keep the Alpha's time_t the same size as the i386's. -- -- 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 Sun Oct 28 17:16: 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 B1D9937B403; Sun, 28 Oct 2001 17:16:01 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9T1FrB33162; Sun, 28 Oct 2001 17:15:53 -0800 (PST) (envelope-from obrien) Date: Sun, 28 Oct 2001 17:15:53 -0800 From: "David O'Brien" To: Garance A Drosihn Cc: Marcel Moolenaar , Peter Wemm , Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86, votes Message-ID: <20011028171553.E32015@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net> 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 Sat, Oct 27, 2001 at 05:51:42PM -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 27, 2001 at 05:51:42PM -0400, Garance A Drosihn wrote: > 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'. You left out the Alpha (not surprising as most here seem to ignore 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 28 17:17: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 CB6E637B401; Sun, 28 Oct 2001 17:17:54 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9T1HsW33192; Sun, 28 Oct 2001 17:17:54 -0800 (PST) (envelope-from obrien) Date: Sun, 28 Oct 2001 17:17:54 -0800 From: "David O'Brien" To: John Baldwin Cc: Matthew Dillon , arch@FreeBSD.org, Mike Smith Subject: Re: time_t not to change size on x86 Message-ID: <20011028171754.F32015@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200110270636.f9R6aik43419@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 jhb@FreeBSD.org on Sat, Oct 27, 2001 at 02:39:24AM -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 Sat, Oct 27, 2001 at 02:39:24AM -0700, John Baldwin wrote: > 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'). Alpha should be changed when i386 is. -- -- 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 Sun Oct 28 17:35:41 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 020A337B408 for ; Sun, 28 Oct 2001 17:35:29 -0800 (PST) Received: (qmail 13982 invoked from network); 29 Oct 2001 01:35: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 ; 29 Oct 2001 01:35: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: <20011028171754.F32015@dragon.nuxi.com> Date: Sun, 28 Oct 2001 17:35:24 -0700 (PST) From: John Baldwin To: "David O'Brien" Subject: Re: time_t not to change size on x86 Cc: Mike Smith , 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 29-Oct-01 David O'Brien wrote: > On Sat, Oct 27, 2001 at 02:39:24AM -0700, John Baldwin wrote: >> 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'). > > Alpha should be changed when i386 is. Changing alpha isn't near as "bad" as changing i386, as it already passes args in 64-bit registers, so printf won't break, etc. I don't think i386 should ever change, personally, but I don't think it will really break Alpha near as much as i386. -- 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 Sun Oct 28 17:58:49 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 8062737B409 for ; Sun, 28 Oct 2001 17:58:42 -0800 (PST) Received: (qmail 52628 invoked from network); 29 Oct 2001 01:58:41 -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 ; 29 Oct 2001 01:58:41 -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: <20011028171418.D32015@dragon.nuxi.com> Date: Sun, 28 Oct 2001 17:58:41 -0700 (PST) From: John Baldwin To: "David O'Brien" Subject: Re: time_t not to change size on x86 Cc: arch@FreeBSD.ORG, Mike Smith , Matthew Dillon , Peter Wemm , Marcel Moolenaar , Jim Pirzyk Sender: owner-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 29-Oct-01 David O'Brien wrote: > On Sat, Oct 27, 2001 at 12:51:28PM -0700, Jim Pirzyk wrote: >> >> I too agree that we should change time_t on the 64bit >> >> platforms and leave the i386 platform alone. > > Since people are resisting moving i386 to a 64-bit time_t, only the Alpha > users should be able to vote what happens on their platform. > > Matt Dillon has found bugs where code assumed sizeof(time_t) == > sizeof(int), which was benign on the i386, would have been deadly on the > Alpha. And this is *precisely* why I have fought to keep the Alpha's > time_t the same size as the i386's. I am somewhat divided on this as well. I would like time_t to be a long on all platforms. However, given that the Alpha's future development is dead and that it probably won't be in use come 2038, I fear the usefulness of bumping it's time_t isn't worth the hastle. -- 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 Sun Oct 28 17:58:50 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 150EB37B40A for ; Sun, 28 Oct 2001 17:58:41 -0800 (PST) Received: (qmail 52599 invoked from network); 29 Oct 2001 01:58:40 -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 ; 29 Oct 2001 01:58:40 -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: <19523.1004213808@critter.freebsd.dk> Date: Sun, 28 Oct 2001 17:58:39 -0700 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: Re: time_t not to change size on x86 Cc: arch@FreeBSD.ORG, Mike Smith , Matthew Dillon , 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 27-Oct-01 Poul-Henning Kamp wrote: > 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++") Borland's extended Pascal. /me ducks and runs -- 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 Sun Oct 28 18:30: 5 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 C617537B405; Sun, 28 Oct 2001 18:30:00 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9T2h2c04281; Sun, 28 Oct 2001 18:43:02 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200110290243.f9T2h2c04281@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: obrien@FreeBSD.org Cc: John Baldwin , Matthew Dillon , arch@FreeBSD.org, Mike Smith Subject: Re: time_t not to change size on x86 In-reply-to: Your message of "Sun, 28 Oct 2001 17:17:54 PST." <20011028171754.F32015@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Oct 2001 18:43:02 -0800 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 > On Sat, Oct 27, 2001 at 02:39:24AM -0700, John Baldwin wrote: > > 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'). > > Alpha should be changed when i386 is. This is part of the point in using 'long'; there's an implicit assumption that the Alpha, long our 64-bit testbed will bear the brunt of the confusion in the early stages of the migration. Being an Alpha supporter has never been easy. 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 28 18:31:45 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 4EBE237B407; Sun, 28 Oct 2001 18:31:41 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9T2ihc04347; Sun, 28 Oct 2001 18:44:43 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200110290244.f9T2ihc04347@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 In-reply-to: Your message of "Sun, 28 Oct 2001 17:35:24 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Oct 2001 18:44:42 -0800 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 > Changing alpha isn't near as "bad" as changing i386, as it already passes arg > s > in 64-bit registers, so printf won't break, etc. I don't think i386 should > ever change, personally, but I don't think it will really break Alpha near as > much as i386. As with most folk, you forget pass-by-reference here. 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 28 18:44:40 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 8809037B403 for ; Sun, 28 Oct 2001 18:44:38 -0800 (PST) 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 f9T2iaa38572 for ; Sun, 28 Oct 2001 21:44:36 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011028171553.E32015@dragon.nuxi.com> References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net> <20011028171553.E32015@dragon.nuxi.com> Date: Sun, 28 Oct 2001 21:44:33 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: time_t not to change size on x86, votes 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:15 PM -0800 10/28/01, David O'Brien wrote: >On Sat, Oct 27, 2001, Garance A Drosihn wrote: > > 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'. > >You left out the Alpha (not surprising as most here seem to ignore >it...) I think those who run Alpha should vote on Alpha. I do not run Alpha, and do not expect that I personally will get an Alpha machine. Still, I should have listed it, and I guess I should vote. Issue: e) Alpha should have a 64-bit time_t in 5.0-release My vote: 4.5 - but I am willing to be outvoted by the people who are actually running freebsd/alpha. -- 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 Sun Oct 28 21: 0:27 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 685E237B406; Sun, 28 Oct 2001 21:00:23 -0800 (PST) Received: (from bmah@localhost) by c527597-a.cstvl1.sfba.home.com (8.11.6/8.11.6) id f9T50Np22107; Sun, 28 Oct 2001 21:00:23 -0800 (PST) (envelope-from bmah) Message-Id: <200110290500.f9T50Np22107@c527597-a.cstvl1.sfba.home.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: obrien@FreeBSD.org Cc: "Bruce A. Mah" , arch@FreeBSD.org Subject: Re: cvs commit: src/contrib/one-true-awk - Imported sources In-Reply-To: <20011028120228.B14028@dragon.nuxi.com> References: <20011028125507.A96876@daemon.ninth-circle.org> <20011029021401.O3597-100000@delplex.bde.org> <20011028103759.A92519@dragon.nuxi.com> <200110281913.f9SJDIY19505@c527597-a.cstvl1.sfba.home.com> <20011028112611.E92519@dragon.nuxi.com> <200110281936.f9SJaGh19709@c527597-a.cstvl1.sfba.home.com> <20011028120228.B14028@dragon.nuxi.com> Comments: In-reply-to "David O'Brien" message dated "Sun, 28 Oct 2001 12:02:28 -0800." From: bmah@FreeBSD.org (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_705459513P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 28 Oct 2001 21:00:23 -0800 Sender: owner-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_705459513P Content-Type: text/plain; charset=us-ascii If memory serves me right, "David O'Brien" wrote: > On Sun, Oct 28, 2001 at 11:36:16AM -0800, Bruce A. Mah wrote: > > Here's the part I'm unclear on. > > > > Permission to use, copy, modify, and distribute this software and > > its documentation for any purpose and without fee is hereby > > granted... > > > > Does "and without fee" apply to granting permission, > > It means we don't have to pay the copyright holder to "use, copy, modify, > and distribute". Hmmm. I was hoping for an explanation of why the other interpretation (deleted by you) wasn't the right one, rather than restatement of your position. Don't get me wrong...I hope you're correct, but I thought some due diligence might be prudent. But if you really want to throw the switch, I won't stand in your way. In any case, if and when bwk replies to my query [1], I'll post back to arch@. Cheers, Bruce. [1] I have this faint hope he'll remember me from when I was a summer student at Bell Labs and thus might be more likely to reply quickly, but I didn't actually work with him directly, it was a long time ago, and that division had a bazillion summer students. Ah well. --==_Exmh_705459513P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE73OJm2MoxcVugUsMRAn1VAJ9RCPrnLWa7n3Ouoc0/OF4Asok5ewCeMMX1 mXpQb/nkcpf6nZAUeWxbMi0= =My+g -----END PGP SIGNATURE----- --==_Exmh_705459513P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 21:17:59 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 BA9F637B403 for ; Sun, 28 Oct 2001 21:17:20 -0800 (PST) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.11.6/8.11.5) with ESMTP id f9T5FMa61978 for ; Mon, 29 Oct 2001 00:15:23 -0500 (EST) (envelope-from mi@aldan.algebra.com) Message-Id: <200110290515.f9T5FMa61978@aldan.algebra.com> Date: Mon, 29 Oct 2001 00:15:19 -0500 (EST) From: Mikhail Teterin Subject: dump(8) and proctitle, SIGINFO To: arch@FreeBSD.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY="0-1714636915-1004332525=:4898" Content-Transfer-Encoding: BINARY Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --0-1714636915-1004332525=:4898 Content-Type: TEXT/plain; charset=us-ascii Well, it took me a while, but here it is :) The last round of reviews had no problem with the proctitle setting itself, but the handling of SIGINFO caused concerns, since it was doing some things a signal handlers are not allowed to do. In this version of the patch, the statistics are not printed immediately in the signal handling. The signal simply reschedules the next statistics-printing after writing the current block. I assume, calling time(3) is fine for a signal handler. I also removed the arbitrary limit, that the amount of blocks written since the last statistics report (5 minutes earlier) needs to be above 500 for the new line of stats to be output. Dump will now print the stats every 5 minutes or after every SIGINFO. Period. Please, review. Thanks! -mi P.S. Should this version cause no objections, could someone, please, advise me at my possible next step -- I'm only a ports commiter, so, I guess, someone else will have to commit this, right? --0-1714636915-1004332525=:4898 Content-Type: TEXT/plain; name=patch-dump-stats-title Content-Description: patch dump(8) to use proctitle and handle SIGINFO Content-Disposition: attachment; filename=patch-dump-stats-title Index: dump.8 =================================================================== RCS file: /home/ncvs/src/sbin/dump/dump.8,v retrieving revision 1.39 diff -U2 -r1.39 dump.8 --- dump.8 2001/07/15 14:00:19 1.39 +++ dump.8 2001/10/29 05:06:26 @@ -320,5 +320,6 @@ .Pp .Nm Dump -tells the operator what is going on at periodic intervals, +tells the operator what is going on at periodic intervals -- +every 5 minutes, or after writing the next block after receiving SIGINFO -- including usually low estimates of the number of blocks to write, the number of tapes it will take, the time to completion, and Index: dump.h =================================================================== RCS file: /home/ncvs/src/sbin/dump/dump.h,v retrieving revision 1.10 diff -U2 -r1.10 dump.h --- dump.h 2001/09/05 15:37:01 1.10 +++ dump.h 2001/10/29 05:06:27 @@ -101,6 +101,7 @@ int query __P((char *question)); void quit __P((const char *fmt, ...)) __printflike(1, 2); -void timeest __P((void)); +void timeest __P((int)); /* accepts the signal number */ time_t unctime __P((char *str)); +void title __P((void)); /* mapping rouintes */ Index: main.c =================================================================== RCS file: /home/ncvs/src/sbin/dump/main.c,v retrieving revision 1.28 diff -U2 -r1.28 main.c --- main.c 2001/10/28 20:01:38 1.28 +++ main.c 2001/10/29 05:06:27 @@ -341,4 +341,5 @@ exit(X_STARTUP); } + title(); sync(); sblock = (struct fs *)sblock_buf; @@ -367,7 +368,9 @@ msg("mapping (Pass I) [regular files]\n"); + title(); anydirskipped = mapfiles(maxino, &tapesize); msg("mapping (Pass II) [directories]\n"); + title(); while (anydirskipped) { anydirskipped = mapdirs(maxino, &tapesize); @@ -419,4 +422,5 @@ tapesize, fetapes); } + title(); /* @@ -432,4 +436,5 @@ msg("dumping (Pass III) [directories]\n"); + title(); dirty = 0; /* XXX just to get gcc to shut up */ for (map = dumpdirmap, ino = 1; ino < maxino; ino++) { @@ -450,4 +455,5 @@ msg("dumping (Pass IV) [regular files]\n"); + title(); for (map = dumpinomap, ino = 1; ino < maxino; ino++) { int mode; @@ -487,4 +493,5 @@ tend_writing - tstart_writing, spcl.c_tapea / (tend_writing - tstart_writing)); + title(); putdumptime(); @@ -545,4 +552,5 @@ quit("Signal on pipe: cannot recover\n"); msg("Rewriting attempted as response to unknown signal.\n"); + title(); (void)fflush(stderr); (void)fflush(stdout); Index: optr.c =================================================================== RCS file: /home/ncvs/src/sbin/dump/optr.c,v retrieving revision 1.15 diff -U2 -r1.15 optr.c --- optr.c 2001/10/28 06:13:47 1.15 +++ optr.c 2001/10/29 05:06:27 @@ -191,14 +191,23 @@ void -timeest() +timeest(signal) { time_t tnow; int deltat; - (void) time((time_t *) &tnow); + (void) time(&tnow); + if (signal != 0) { + /* + * We might be called to handle SIGINFO. Re-schedule + * the reporting to occur the next time we are called + * regularly and bail out -- don't do reporting as a + * signal handler -- it involves malloc-ing and other + * things signal handler are not supposed to do. + */ + tschedule = tnow; + return; + } if (tnow >= tschedule) { tschedule = tnow + 300; - if (blockswritten < 500) - return; deltat = tstart_writing - tnow + (1.0 * (tnow - tstart_writing)) @@ -207,4 +216,5 @@ (blockswritten * 100.0) / tapesize, deltat / 3600, (deltat % 3600) / 60); + title(); } } @@ -235,4 +245,31 @@ (void) vsnprintf(lastmsg, sizeof(lastmsg), fmt, ap); va_end(ap); +} + +/* + * This function can be called to place, what msg() above pushed to + * stderr, into the process title, viewable with the ps-command. + * A side effect of this function, is it replaces the final '\n' (if any) + * with the '\0' in the global variable lastmsg -- to avoid the literal + * "\n" being put into the proctitle. + * So, if the lastmsg needs to be output elsewhere, that should happen + * before calling title(). + */ +void title() +{ + int lastlen; + + lastlen = strlen(lastmsg); + if (lastmsg[lastlen-1] == '\n') + lastmsg[lastlen-1] = '\0'; + + /* + * It would be unwise to run multiple dumps of same disk + * at the same time. So ``disk'' is sufficient for + * identifying, to which family of dump processes this + * one belongs -- the other processes continue to have + * the original titles. + */ + setproctitle("%s: %s", disk, lastmsg); } Index: tape.c =================================================================== RCS file: /home/ncvs/src/sbin/dump/tape.c,v retrieving revision 1.13 diff -U2 -r1.13 tape.c --- tape.c 2001/01/28 21:21:37 1.13 +++ tape.c 2001/10/29 05:06:28 @@ -315,5 +315,5 @@ startnewtape(0); } - timeest(); + timeest(0); } @@ -532,4 +532,5 @@ * All signals are inherited... */ + setproctitle(NULL); /* restore the proctitle modified by title() */ childpid = fork(); if (childpid < 0) { @@ -622,4 +625,5 @@ enslave(); /* Share open tape file descriptor with slaves */ + signal(SIGINFO, timeest); /* report progress on SIGINFO */ asize = 0; --0-1714636915-1004332525=:4898-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 28 22:26:31 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 8639437B401; Sun, 28 Oct 2001 22:26:18 -0800 (PST) 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 f9T6QIM56590; Sun, 28 Oct 2001 22:26:18 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 396303808; Sun, 28 Oct 2001 22:26:18 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mike Smith Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: <200110290244.f9T2ihc04347@mass.dis.org> Date: Sun, 28 Oct 2001 22:26:18 -0800 From: Peter Wemm Message-Id: <20011029062618.396303808@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: > > Changing alpha isn't near as "bad" as changing i386, as it already passes a rg > > s > > in 64-bit registers, so printf won't break, etc. I don't think i386 should > > ever change, personally, but I don't think it will really break Alpha near as > > much as i386. > > As with most folk, you forget pass-by-reference here. 8) We had one of these in the ACPICA code recently. :-) A pointer to int had been cast that hid the fact that it was a 32/64 bit mismatch. *NO* compiler warnings will detect that. Specifically, it was: int i; int j; bus_read_ivar(dev, ....., (uintptr_t *)&i); .. which was silently accepted by the compiler. And 'i' was written as a 'long' and consequently trashed the 'j' variable that was on the stack right after it. (uintptr_t is 64 bit on non-i386) We risk the same problem in 3rd party apps. 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 Sun Oct 28 22:43:18 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 130C737B416 for ; Sun, 28 Oct 2001 22:42:58 -0800 (PST) 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 f9T6gvM56615 for ; Sun, 28 Oct 2001 22:42:57 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id ACB573808; Sun, 28 Oct 2001 22:42:57 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: calm, orderly, deliberate time_t transition.. In-Reply-To: Date: Sun, 28 Oct 2001 22:42:56 -0800 From: Peter Wemm Message-Id: <20011029064257.ACB573808@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 Garance A Drosihn wrote: > At 5:15 PM -0800 10/28/01, David O'Brien wrote: > >On Sat, Oct 27, 2001, Garance A Drosihn wrote: > > > 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'. > > > >You left out the Alpha (not surprising as most here seem to ignore > >it...) > > I think those who run Alpha should vote on Alpha. I do not run > Alpha, and do not expect that I personally will get an Alpha > machine. > > Still, I should have listed it, and I guess I should vote. > > Issue: > e) Alpha should have a 64-bit time_t in 5.0-release > > My vote: > 4.5 - but I am willing to be outvoted by the people who are > actually running freebsd/alpha. Actually, I think the most sensible thing to do here is work from what we do agree on backwards, and save the most risky things till last so that we have gained experience. I think what we do agree on: 1: time_t assumptions in existing code should be fixed. 2: new platforms should start at time_t 64 bit 3: Once we've tested the water on the new platforms, *then* progress towards activating it on alpha and then x86. By then we'll have gathered enough *experience* on the new platforms to know how much pain the alpha and i386 will have, and we can judge whether its worth it. Until then, we're speculating. We have no hard data and no actual real experience. If we can agree that the ideal goal is to move toward 64 bit times in a sane and orderly fashion, and that each major hurdle is to be evaluted as we come to it, then we can end this damn bikeshed-from-hell and just get on with 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 Mon Oct 29 1:29: 1 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 8547D37B407 for ; Mon, 29 Oct 2001 01:28:57 -0800 (PST) Received: (qmail 70899 invoked from network); 29 Oct 2001 09:28:56 -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 ; 29 Oct 2001 09:28:56 -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: <200110290244.f9T2ihc04347@mass.dis.org> Date: Mon, 29 Oct 2001 01:28:56 -0800 (PST) From: John Baldwin To: Mike Smith Subject: Re: time_t not to change size on x86 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 On 29-Oct-01 Mike Smith wrote: >> Changing alpha isn't near as "bad" as changing i386, as it already passes >> arg >> s >> in 64-bit registers, so printf won't break, etc. I don't think i386 should >> ever change, personally, but I don't think it will really break Alpha near >> as >> much as i386. > > As with most folk, you forget pass-by-reference here. 8) It still may not be as fatal. If alpha aligns structures on 8 byte boundaries to avoid alignment problems, then you will actually have 8 bytes regardless. Depends on how strict the alignment is, though. -- 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 Mon Oct 29 2:16:55 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 5E67337B405 for ; Mon, 29 Oct 2001 02:16:49 -0800 (PST) Received: (qmail 1659 invoked from network); 29 Oct 2001 10:16:48 -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 ; 29 Oct 2001 10:16:48 -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 Date: Mon, 29 Oct 2001 02:16:37 -0800 (PST) From: John Baldwin To: arch@FreeBSD.org Subject: syscall() ABI questions Sender: owner-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 got some questions about td->td_retval[1] and our syscall ABI. On some archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, sparc64, ppc) we set it to the value of the register it will be set to so that effectively this register's value is preserved across the syscall. My question is do our syscall ABI's actually assume that for syscalls with only one return value that register isn't written to? NetBSD recently changed their i386 syscall code to preinitialize to 0 rather than %edx. Anyone have the history on this? Speaking of i386, I have another question. For the fork, vfork, and rfork syscalls, we have custom handlers that call the syscall normally and then explicitly zero the return value if %edx is 1 (i.e., the child). However, in vm_fork(), we already explicitly set the value in %eax to 0 for child processes, so is this extra setting of that value in libc really needed? If not, we can safely get rid of rfork.S, vfork.S, and fork.S in libc I think. -- 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 Mon Oct 29 6: 0:48 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 ED8ED37B405 for ; Mon, 29 Oct 2001 06:00:40 -0800 (PST) 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 JAA23650; Mon, 29 Oct 2001 09:00:36 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f9TE0AL03900; Mon, 29 Oct 2001 09:00:10 -0500 (EST) (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: <15325.24809.802579.778980@grasshopper.cs.duke.edu> Date: Mon, 29 Oct 2001 09:00:09 -0500 (EST) To: Garance A Drosihn Cc: arch@FreeBSD.ORG Reply-To: arch@FreeBSD.ORG 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> <20011028171553.E32015@dragon.nuxi.com> 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 Garance A Drosihn writes: > > I think those who run Alpha should vote on Alpha. I do not run > Alpha, and do not expect that I personally will get an Alpha > machine. As an alpha user, I feel that the alpha should NOT be migrated to a 64-bit time_t until & unless the i386 is migrated. I think we all can agree that due to a corporate knife in the back, the alpha will have a much shorter lifespan than the x86. I seriously doubt there will be any alphas running FreeBSD 36 years from now. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 6:43:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 6271837B40C; Mon, 29 Oct 2001 06:43:36 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 15yDdS-00032m-0C; Mon, 29 Oct 2001 14:43:30 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9TEgE742924; Mon, 29 Oct 2001 14:42:14 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 29 Oct 2001 14:42:14 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Subject: Re: syscall() ABI questions In-Reply-To: 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, 29 Oct 2001, John Baldwin wrote: > I've got some questions about td->td_retval[1] and our syscall ABI. On some > archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, > sparc64, ppc) we set it to the value of the register it will be set to so that > effectively this register's value is preserved across the syscall. My question > is do our syscall ABI's actually assume that for syscalls with only one return > value that register isn't written to? NetBSD recently changed their i386 > syscall code to preinitialize to 0 rather than %edx. Anyone have the history > on this? For ia64 and alpha, it is safe to pre-initialise to zero. The register used in both cases is a scratch register. In ia64, there are actually four return value registers defined by the calling convention and we use the second one (r9) for td_retval[1] and the third one (r10) for the error flag. > > Speaking of i386, I have another question. For the fork, vfork, and rfork > syscalls, we have custom handlers that call the syscall normally and then > explicitly zero the return value if %edx is 1 (i.e., the child). However, in > vm_fork(), we already explicitly set the value in %eax to 0 for child > processes, so is this extra setting of that value in libc really needed? If > not, we can safely get rid of rfork.S, vfork.S, and fork.S in libc I think. Come to think of it, we probably can get rid of the fork wrappers. I haven't tried it though. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 9: 4:16 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 6896737B401 for ; Mon, 29 Oct 2001 09:04:13 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Mon, 29 Oct 2001 17:04:11 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 15yFo8-0005OE-00; Mon, 29 Oct 2001 17:02:40 +0000 Date: Mon, 29 Oct 2001 17:02:39 +0000 (GMT) From: Jan Grant X-X-Sender: To: arch Subject: Re: time_t not to change size on x86, votes In-Reply-To: <15325.24809.802579.778980@grasshopper.cs.duke.edu> 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, 29 Oct 2001, Andrew Gallatin wrote: > Garance A Drosihn writes: > > > > I think those who run Alpha should vote on Alpha. I do not run > > Alpha, and do not expect that I personally will get an Alpha > > machine. > > As an alpha user, I feel that the alpha should NOT be migrated to a > 64-bit time_t until & unless the i386 is migrated. I think we all can > agree that due to a corporate knife in the back, the alpha will have a > much shorter lifespan than the x86. I seriously doubt there will be > any alphas running FreeBSD 36 years from now. What are the filesystem implications of a 64-bit timestamp? I've not juggled disks with FBSD - are FBSD filesystems portable across architectures? - and if so, do they remain so if some platforms get the larger timestamp? jan PS. Seem to recall 64 bits of space around a timestamp in inodes, but my memory's not what it was. RTFS, and I should cocoa. -- 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 (Things I've found in my attic, #2: A hundredweight of pornography.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 9: 6:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 5F7CA37B40C for ; Mon, 29 Oct 2001 09:06:43 -0800 (PST) Received: from dialup-209.245.136.208.dial1.sanjose1.level3.net ([209.245.136.208] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15yFrz-0002Bi-00; Mon, 29 Oct 2001 09:06:39 -0800 Message-ID: <3BDD8CBF.80D85ED4@mindspring.com> Date: Mon, 29 Oct 2001 09:07:11 -0800 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: Peter Wemm Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: calm, orderly, deliberate time_t transition.. References: <20011029064257.ACB573808@overcee.netplex.com.au> 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 Peter Wemm wrote: > 2: new platforms should start at time_t 64 bit > > 3: Once we've tested the water on the new platforms, *then* progress > towards activating it on alpha and then x86. > > By then we'll have gathered enough *experience* on the new platforms to > know how much pain the alpha and i386 will have, and we can judge whether > its worth it. Until then, we're speculating. We have no hard data and > no actual real experience. The problem with this is that it pushes both the onus and all the experience off onto the new platform people. FreeBSD already has a considerable x86 bias that any attempt at a new platform has to overcome, just to boot. Putting what amount to gratuitous changes in the path of them is just that much more barrier to entry. It would be an amazing pain to have something that would not work on i386 as 64 bits bite you on the butt merely because on your new platform, it's mandated that it has to change from the i386. What you're basically asking is for people to do ports blind, with a reference platform where the code is potentially substantially different from that expected of the target platform. IMO, the amount of platform dependent code should be minimized, not added to, by whatever policy you end up setting in stone. The 32 bit x86 platform will not live forever... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 9: 9: 2 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 9465337B40D; Mon, 29 Oct 2001 09:08:59 -0800 (PST) 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 EAA31797; Tue, 30 Oct 2001 04:08:56 +1100 Date: Tue, 30 Oct 2001 04:07:56 +1100 (EST) From: Bruce Evans X-X-Sender: To: John Baldwin Cc: Subject: Re: syscall() ABI questions In-Reply-To: Message-ID: <20011030035059.L12873-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 Mon, 29 Oct 2001, John Baldwin wrote: > I've got some questions about td->td_retval[1] and our syscall ABI. On some > archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, > sparc64, ppc) we set it to the value of the register it will be set to so that > effectively this register's value is preserved across the syscall. My question > is do our syscall ABI's actually assume that for syscalls with only one return > value that register isn't written to? NetBSD recently changed their i386 > syscall code to preinitialize to 0 rather than %edx. Anyone have the history > on this? Not me. It's older than FreeBSD-1.1. It seems to be just a pessimization to preinitialize retval[1]. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 9:12: 4 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 9AD1337B403 for ; Mon, 29 Oct 2001 09:12:01 -0800 (PST) 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 f9THBxf25912; Mon, 29 Oct 2001 12:12:00 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011029064257.ACB573808@overcee.netplex.com.au> References: <20011029064257.ACB573808@overcee.netplex.com.au> Date: Mon, 29 Oct 2001 12:11:57 -0500 To: Peter Wemm From: Garance A Drosihn Subject: Re: calm, orderly, deliberate time_t transition.. 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:42 PM -0800 10/28/01, Peter Wemm wrote: >I think what we do agree on: > > 1: time_t assumptions in existing code should be fixed. > > 2: new platforms should start at time_t 64 bit > > 3: Once we've tested the water on the new platforms, *then* > progress towards activating it on alpha and then x86. >If we can agree that the ideal goal is to move toward 64 bit times >in a sane and orderly fashion, and that each major hurdle is to be >evaluted as we come to it, then we can end this bikeshed-from-hell >and just get on with it. This sounds good to me. -- 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 Mon Oct 29 9:21:44 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 B84D737B40A for ; Mon, 29 Oct 2001 09:21:40 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA22254; Mon, 29 Oct 2001 10:21:34 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id f9THLYS18191; Mon, 29 Oct 2001 10:21:34 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15325.36894.320057.967406@caddis.yogotech.com> Date: Mon, 29 Oct 2001 10:21:34 -0700 To: Poul-Henning Kamp Cc: Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <24137.1004080687@critter.freebsd.dk> References: <24137.1004080687@critter.freebsd.dk> 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 > >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.... Simply not true. We have pico second resolution in our product, which is necessary because we're using *really* fast transports, and need to do very precise timing. (We're not using FreeBSD now, but if we need that kind of resolution in 2001, I can easily see the need for much higher resolution in the future.) I'm with PHK here (can you believe it?). :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 9:27:32 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 73D2737B413 for ; Mon, 29 Oct 2001 09:27:16 -0800 (PST) Received: (qmail 48366 invoked from network); 29 Oct 2001 17:27:14 -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 ; 29 Oct 2001 17:27:14 -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: <20011030035059.L12873-100000@delplex.bde.org> Date: Mon, 29 Oct 2001 09:27:04 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: syscall() ABI questions 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 On 29-Oct-01 Bruce Evans wrote: > On Mon, 29 Oct 2001, John Baldwin wrote: > >> I've got some questions about td->td_retval[1] and our syscall ABI. On some >> archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, >> sparc64, ppc) we set it to the value of the register it will be set to so >> that >> effectively this register's value is preserved across the syscall. My >> question >> is do our syscall ABI's actually assume that for syscalls with only one >> return >> value that register isn't written to? NetBSD recently changed their i386 >> syscall code to preinitialize to 0 rather than %edx. Anyone have the >> history >> on this? > > Not me. It's older than FreeBSD-1.1. It seems to be just a pessimization > to preinitialize retval[1]. That's depressing. I was hoping you would know what was going on here. :) > Bruce -- 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 Mon Oct 29 9:27:38 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 1D53B37B403 for ; Mon, 29 Oct 2001 09:27:18 -0800 (PST) Received: (qmail 48405 invoked from network); 29 Oct 2001 17:27:15 -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 ; 29 Oct 2001 17:27:15 -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: Mon, 29 Oct 2001 09:27:05 -0800 (PST) From: John Baldwin To: Doug Rabson Subject: Re: syscall() ABI questions 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 On 29-Oct-01 Doug Rabson wrote: > On Mon, 29 Oct 2001, John Baldwin wrote: > >> I've got some questions about td->td_retval[1] and our syscall ABI. On some >> archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, >> sparc64, ppc) we set it to the value of the register it will be set to so >> that >> effectively this register's value is preserved across the syscall. My >> question >> is do our syscall ABI's actually assume that for syscalls with only one >> return >> value that register isn't written to? NetBSD recently changed their i386 >> syscall code to preinitialize to 0 rather than %edx. Anyone have the >> history >> on this? > > For ia64 and alpha, it is safe to pre-initialise to zero. The register > used in both cases is a scratch register. In ia64, there are actually four > return value registers defined by the calling convention and we use the > second one (r9) for td_retval[1] and the third one (r10) for the error > flag. %edx isn't call safe on i386, so it should be safe to 0 that one as well. I guess it is arch-specific however and we can't assume that we can set it to 0 on all archs? >> Speaking of i386, I have another question. For the fork, vfork, and rfork >> syscalls, we have custom handlers that call the syscall normally and then >> explicitly zero the return value if %edx is 1 (i.e., the child). However, >> in >> vm_fork(), we already explicitly set the value in %eax to 0 for child >> processes, so is this extra setting of that value in libc really needed? If >> not, we can safely get rid of rfork.S, vfork.S, and fork.S in libc I think. > > Come to think of it, we probably can get rid of the fork wrappers. I > haven't tried it though. I'll try it here locally then. -- 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 Mon Oct 29 9:46: 4 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 DF54837B406 for ; Mon, 29 Oct 2001 09:45:58 -0800 (PST) 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 f9THjtf101138; Mon, 29 Oct 2001 12:45:55 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3BDD8CBF.80D85ED4@mindspring.com> References: <20011029064257.ACB573808@overcee.netplex.com.au> <3BDD8CBF.80D85ED4@mindspring.com> Date: Mon, 29 Oct 2001 12:45:52 -0500 To: tlambert2@mindspring.com, Peter Wemm From: Garance A Drosihn Subject: Re: calm, orderly, deliberate time_t transition.. 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 9:07 AM -0800 10/29/01, Terry Lambert wrote: >Peter Wemm wrote: >> 2: new platforms should start at time_t 64 bit >> > > 3: Once we've tested the water on the new platforms, *then* > > progress towards activating it on alpha and then x86. > >The problem with this is that it pushes both the onus and all >the experience off onto the new platform people. > >FreeBSD already has a considerable x86 bias that any attempt >at a new platform has to overcome, just to boot. Putting >what amount to gratuitous changes in the path of them is just >that much more barrier to entry. Speaking for my own situation, I already own PowerPC systems and I have no qualms about buying more. I'll be happy to run FreeBSD for PowerPC just as soon as the "basic operating system" level is working (I don't work at the kernel level, so I'd want something booting into multi-user and reasonably stable at the kernel/device-driver layers). I want 64-bit time_t's, and I don't see that issue as any barrier to my running FreeBSD/ppc. We have to start somewhere, and in my mind it makes good sense to start on platforms which we KNOW are not currently running any "in production" services. If we don't move i386 and Alpha to 64-bit time_t's in 5.0, then we can still think about doing it for 6.0. This would mean the "new platforms" are running 64-bit as 5.0-stable at the same time that i386 and alpha are running it as 6.0-current. So, any bugs come up for 64-bit time_t's on i386 will be seen in the current branch at the same time the "new platform people" might be seeing similar problems in their stable branch. I am sure we can find *some* problem with any suggested course of action. This course of action is not perfect either, but I think it's reasonable. -- 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 Mon Oct 29 9:46: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 048E937B403 for ; Mon, 29 Oct 2001 09:46:17 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9THk2713600; Mon, 29 Oct 2001 12:46:02 -0500 (EST) (envelope-from wollman) Date: Mon, 29 Oct 2001 12:46:02 -0500 (EST) From: Garrett Wollman Message-Id: <200110291746.f9THk2713600@khavrinen.lcs.mit.edu> To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011029064937.C75481@gsmx07.alcatel.com.au> References: <20011025233602.587C63808@overcee.netplex.com.au> <200110260020.f9Q0KQR63759@khavrinen.lcs.mit.edu> <20011029064937.C75481@gsmx07.alcatel.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 < said: > exponential growth in the number of syscalls: Consider a hypothetical > system that has two off_t sizes and two time_t sizes - it will need 4 > stat() syscalls (and maybe others). Actually, no; there are just two options: 1) Data types other than off_t might be C99 ``extended integral types''. 2) Data types other than off_t are not C99 ``extended integral types''. ...since we never supported the LFS extensions. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 9:59:45 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 E51DD37B403 for ; Mon, 29 Oct 2001 09:59:39 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9THx6P01010; Mon, 29 Oct 2001 09:59:07 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200110291759.f9THx6P01010@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: tlambert2@mindspring.com Cc: Peter Wemm , Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: calm, orderly, deliberate time_t transition.. In-reply-to: Your message of "Mon, 29 Oct 2001 09:07:11 PST." <3BDD8CBF.80D85ED4@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Oct 2001 09:59:06 -0800 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 > IMO, the amount of platform dependent code should be minimized, > not added to, by whatever policy you end up setting in stone. > The 32 bit x86 platform will not live forever... This is why time_t should probably just become "long". Earlier points about the risks of making it a non-integral type are also pretty salient. It will expose threaded programs to some very nasty race conditions which I am sure that the change's proponents will say aren't their problem. -- ... 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 Mon Oct 29 10:22:29 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 04EB637B401 for ; Mon, 29 Oct 2001 10:22:27 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA26402; Mon, 29 Oct 2001 10:14:22 -0800 (PST) Date: Mon, 29 Oct 2001 10:14:20 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <15325.36894.320057.967406@caddis.yogotech.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 yes you are right here.. But the two TOP bits of the nanosecond fields are by definition always 0 (you can only have up to 1,000,000,000 nano seconds in a partial second) and 32 bits goes up to 4(American)billion, so the two top bits can safely be used for multiplying the seconds scale by 4. (in UFS timestamps.. you would never write a non-normalised time to disk) also timestamps can't be before 1970 so making it unsigned allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. On Mon, 29 Oct 2001, Nate Williams wrote: > > >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.... > > Simply not true. We have pico second resolution in our product, which > is necessary because we're using *really* fast transports, and need to > do very precise timing. > > (We're not using FreeBSD now, but if we need that kind of resolution in > 2001, I can easily see the need for much higher resolution in the > future.) > > I'm with PHK here (can you believe it?). :) :) > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 10:40:12 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 585B637B421 for ; Mon, 29 Oct 2001 10:40:08 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA25437; Mon, 29 Oct 2001 11:40:01 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id f9TIe1A18619; Mon, 29 Oct 2001 11:40:01 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15325.41600.832823.952280@caddis.yogotech.com> Date: Mon, 29 Oct 2001 11:40:00 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: References: <15325.36894.320057.967406@caddis.yogotech.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 > yes you are right here.. > > But the two TOP bits of the nanosecond fields > are by definition always 0 > (you can only have up to 1,000,000,000 nano seconds in a partial second) > and 32 bits goes up to 4(American)billion, so the two top bits can safely > be used for multiplying the seconds scale by 4. (in UFS timestamps.. > you would never write a non-normalised time to disk) > also timestamps can't be before 1970 so making it unsigned > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. All I can say is *yuck*. Nate > > > >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.... > > > > Simply not true. We have pico second resolution in our product, which > > is necessary because we're using *really* fast transports, and need to > > do very precise timing. > > > > (We're not using FreeBSD now, but if we need that kind of resolution in > > 2001, I can easily see the need for much higher resolution in the > > future.) > > > > I'm with PHK here (can you believe it?). :) :) > > > > > > Nate > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 11:33:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from p3.locore.ca (p3.locore.ca [198.96.117.171]) by hub.freebsd.org (Postfix) with ESMTP id 482B137B403; Mon, 29 Oct 2001 11:33:46 -0800 (PST) Received: (from jake@localhost) by p3.locore.ca (8.11.4/8.11.4) id f9TJVrw39076; Mon, 29 Oct 2001 14:31:53 -0500 (EST) (envelope-from jake) Date: Mon, 29 Oct 2001 14:31:53 -0500 From: Jake Burkholder To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: syscall() ABI questions Message-ID: <20011029143153.B14748@locore.ca> 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 Mon, Oct 29, 2001 at 02:16:37AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Mon, Oct 29, 2001 at 02:16:37AM -0800, John Baldwin said words to the effect of; > I've got some questions about td->td_retval[1] and our syscall ABI. On some > archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, > sparc64, ppc) we set it to the value of the register it will be set to so that > effectively this register's value is preserved across the syscall. My question > is do our syscall ABI's actually assume that for syscalls with only one return > value that register isn't written to? NetBSD recently changed their i386 > syscall code to preinitialize to 0 rather than %edx. Anyone have the history > on this? > > Speaking of i386, I have another question. For the fork, vfork, and rfork > syscalls, we have custom handlers that call the syscall normally and then > explicitly zero the return value if %edx is 1 (i.e., the child). However, in > vm_fork(), we already explicitly set the value in %eax to 0 for child > processes, so is this extra setting of that value in libc really needed? If > not, we can safely get rid of rfork.S, vfork.S, and fork.S in libc I think. The thing to watch for is that the system call wrappers don't follow the same conventions for call-safe registers. At least on i386 vfork stashes the return address in %ecx and expects it not to be clobbered by the kernel. I think all the warppers that do this use %ecx (not %edx) and its the same on sparc64, %o0 and %o1 are assumed to be clobbered but other otherwise non-call safe registers are assumed to be preserved. So it should be ok to always clobber retval[1] by setting it to zero. I think you're right about fork and rfork being able to use the MIASM code. rfork with RFMEM is special but it can';t be safely called from C anyway. The vfork wrapper needs to stay on x86 at least because both processes return to the same stack; if the retunr address is not saved in a register the child may clobber the parent's when it "rets" and pops the stack. > > -- > > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 11:51:28 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 74C6E37B40A for ; Mon, 29 Oct 2001 11:51:21 -0800 (PST) Received: (qmail 36642 invoked from network); 29 Oct 2001 19:51:19 -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 ; 29 Oct 2001 19:51:19 -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: <20011029143153.B14748@locore.ca> Date: Mon, 29 Oct 2001 11:50:58 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: Re: syscall() ABI questions 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 On 29-Oct-01 Jake Burkholder wrote: > Apparently, On Mon, Oct 29, 2001 at 02:16:37AM -0800, > John Baldwin said words to the effect of; > >> I've got some questions about td->td_retval[1] and our syscall ABI. On some >> archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, >> sparc64, ppc) we set it to the value of the register it will be set to so >> that >> effectively this register's value is preserved across the syscall. My >> question >> is do our syscall ABI's actually assume that for syscalls with only one >> return >> value that register isn't written to? NetBSD recently changed their i386 >> syscall code to preinitialize to 0 rather than %edx. Anyone have the >> history >> on this? >> >> Speaking of i386, I have another question. For the fork, vfork, and rfork >> syscalls, we have custom handlers that call the syscall normally and then >> explicitly zero the return value if %edx is 1 (i.e., the child). However, >> in >> vm_fork(), we already explicitly set the value in %eax to 0 for child >> processes, so is this extra setting of that value in libc really needed? If >> not, we can safely get rid of rfork.S, vfork.S, and fork.S in libc I think. > > The thing to watch for is that the system call wrappers don't follow > the same conventions for call-safe registers. At least on i386 vfork > stashes the return address in %ecx and expects it not to be clobbered > by the kernel. I think all the warppers that do this use %ecx (not %edx) > and its the same on sparc64, %o0 and %o1 are assumed to be clobbered > but other otherwise non-call safe registers are assumed to be preserved. > So it should be ok to always clobber retval[1] by setting it to zero. > > I think you're right about fork and rfork being able to use the MIASM > code. rfork with RFMEM is special but it can';t be safely called from > C anyway. The vfork wrapper needs to stay on x86 at least because both > processes return to the same stack; if the retunr address is not saved in > a register the child may clobber the parent's when it "rets" and pops > the stack. Same kernel stack? The register is set in the trapframe which means it is saved on the kernel stack. Is that shared in the vfork case? -- 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 Mon Oct 29 11:55:15 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 9781B37B401 for ; Mon, 29 Oct 2001 11:55:06 -0800 (PST) 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 f9TJt40H005077; Mon, 29 Oct 2001 12:55:05 -0700 (MST) Message-Id: <200110291955.f9TJt40H005077@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Giorgos Keramidas Cc: arch@FreeBSD.ORG Subject: GNU Compiler Symlinks In-Reply-To: Message from Giorgos Keramidas of "Sat, 27 Oct 2001 22:42:56 +0300." <20011027224256.A35705@hades.hell.gr> Date: Mon, 29 Oct 2001 12:55:04 -0700 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 >>>>> "Giorgos" == Giorgos Keramidas writes: Giorgos> In that case, I stand corrected :) If the default will be Giorgos> to still make a link cc -> gcc (and all their friends, Giorgos> like c++, etc), then this does not soundn like a bad Giorgos> idea. Not bad at all. Just to clarify, I am not proposing that /usr/bin/c{c,++} be changed in any way. What I'm proposing is (example only): --- /usr/src/gnu/usr.bin/cc/cc/Makefile 2001/10/29 19:35:26 1.1 +++ Makefile 2001/10/29 19:40:03 @@ -5,11 +5,14 @@ .PATH: ${GCCDIR} PROG= cc -MAN= gcc.1 +MAN= cc.1 SRCS= gcc.c gccspec.c +.if !defined(NO_GNU_NAMES) LINKS= ${BINDIR}/cc ${BINDIR}/gcc -MLINKS= gcc.1 cc.1 gcc.1 c++.1 gcc.1 g++.1 gcc.1 CC.1 +MLINKS= cc.1 gcc.1 cc.1 g++.1 +.endif +MLINKS+= cc.1 CC.1 cc.1 c++.1 CFLAGS+= -DDEFAULT_TARGET_VERSION=\"$(version)\" CFLAGS+= -DDEFAULT_TARGET_MACHINE=\"$(target)\" NO_GNU_NAMES=true simply disables the creation of links to the "GNUish" name variants where the GNU tool is installed as part of the base system This appears to only affect the gcc and g++ commands. A couple of people have mentioned that the gcc name has become a defacto standard, so we should just live with it. I don't think that's true. I've run stable for ages without these links, and the only breakage was in a couple of ports, and even those have since been fixed. A more important reason for removing the links is to help with application portability. If you're using FreeBSD as a primary development platform for portable applications, not having gratuitous GNUisms (be they names, or things like awk extensions) makes life easier. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 11:56:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from p3.locore.ca (p3.locore.ca [198.96.117.171]) by hub.freebsd.org (Postfix) with ESMTP id 7F0FB37B401; Mon, 29 Oct 2001 11:56:51 -0800 (PST) Received: (from jake@localhost) by p3.locore.ca (8.11.4/8.11.4) id f9TJswT39222; Mon, 29 Oct 2001 14:54:58 -0500 (EST) (envelope-from jake) Date: Mon, 29 Oct 2001 14:54:58 -0500 From: Jake Burkholder To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: syscall() ABI questions Message-ID: <20011029145458.C14748@locore.ca> References: <20011029143153.B14748@locore.ca> 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 Mon, Oct 29, 2001 at 11:50:58AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Mon, Oct 29, 2001 at 11:50:58AM -0800, John Baldwin said words to the effect of; > > On 29-Oct-01 Jake Burkholder wrote: > > Apparently, On Mon, Oct 29, 2001 at 02:16:37AM -0800, > > John Baldwin said words to the effect of; > > > >> I've got some questions about td->td_retval[1] and our syscall ABI. On some > >> archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, > >> sparc64, ppc) we set it to the value of the register it will be set to so > >> that > >> effectively this register's value is preserved across the syscall. My > >> question > >> is do our syscall ABI's actually assume that for syscalls with only one > >> return > >> value that register isn't written to? NetBSD recently changed their i386 > >> syscall code to preinitialize to 0 rather than %edx. Anyone have the > >> history > >> on this? > >> > >> Speaking of i386, I have another question. For the fork, vfork, and rfork > >> syscalls, we have custom handlers that call the syscall normally and then > >> explicitly zero the return value if %edx is 1 (i.e., the child). However, > >> in > >> vm_fork(), we already explicitly set the value in %eax to 0 for child > >> processes, so is this extra setting of that value in libc really needed? If > >> not, we can safely get rid of rfork.S, vfork.S, and fork.S in libc I think. > > > > The thing to watch for is that the system call wrappers don't follow > > the same conventions for call-safe registers. At least on i386 vfork > > stashes the return address in %ecx and expects it not to be clobbered > > by the kernel. I think all the warppers that do this use %ecx (not %edx) > > and its the same on sparc64, %o0 and %o1 are assumed to be clobbered > > but other otherwise non-call safe registers are assumed to be preserved. > > So it should be ok to always clobber retval[1] by setting it to zero. > > > > I think you're right about fork and rfork being able to use the MIASM > > code. rfork with RFMEM is special but it can';t be safely called from > > C anyway. The vfork wrapper needs to stay on x86 at least because both > > processes return to the same stack; if the retunr address is not saved in > > a register the child may clobber the parent's when it "rets" and pops > > the stack. > > Same kernel stack? The register is set in the trapframe which means it is > saved on the kernel stack. Is that shared in the vfork case? Same user stack. The trapframe is copied to the child's kernel stack. > > -- > > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 11:59: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 CC60737B401 for ; Mon, 29 Oct 2001 11:59:07 -0800 (PST) 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 GAA06818; Tue, 30 Oct 2001 06:58:45 +1100 Date: Tue, 30 Oct 2001 06:57:44 +1100 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , Peter Wemm , Subject: Re: 64 bit times revisited.. In-Reply-To: Message-ID: <20011030065641.B13960-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 Mon, 29 Oct 2001, Julian Elischer wrote: > be used for multiplying the seconds scale by 4. (in UFS timestamps.. > you would never write a non-normalised time to disk) > also timestamps can't be before 1970 so making it unsigned > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. Script started on Tue Oct 30 06:55:55 2001 ttyp1:bde@gamplex:/tmp> touch -t 191001011230 foo ttyp1:bde@gamplex:/tmp> ls -l foo -rw-r--r-- 1 bde wheel 0 Jan 1 1910 foo ttyp1:bde@gamplex:/tmp> exit Script done on Tue Oct 30 06:56:10 2001 Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 11:59:22 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 9C80937B436 for ; Mon, 29 Oct 2001 11:59:13 -0800 (PST) Received: (qmail 90067 invoked from network); 29 Oct 2001 19:59:12 -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 ; 29 Oct 2001 19:59:12 -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: <20011029145458.C14748@locore.ca> Date: Mon, 29 Oct 2001 11:59:01 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: Re: syscall() ABI questions 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 On 29-Oct-01 Jake Burkholder wrote: > Apparently, On Mon, Oct 29, 2001 at 11:50:58AM -0800, > John Baldwin said words to the effect of; > >> >> On 29-Oct-01 Jake Burkholder wrote: >> > Apparently, On Mon, Oct 29, 2001 at 02:16:37AM -0800, >> > John Baldwin said words to the effect of; >> > >> >> I've got some questions about td->td_retval[1] and our syscall ABI. On >> >> some >> >> archs (ia64, alpha) we preinitialie this value to 0. On other archs >> >> (i386, >> >> sparc64, ppc) we set it to the value of the register it will be set to so >> >> that >> >> effectively this register's value is preserved across the syscall. My >> >> question >> >> is do our syscall ABI's actually assume that for syscalls with only one >> >> return >> >> value that register isn't written to? NetBSD recently changed their i386 >> >> syscall code to preinitialize to 0 rather than %edx. Anyone have the >> >> history >> >> on this? >> >> >> >> Speaking of i386, I have another question. For the fork, vfork, and >> >> rfork >> >> syscalls, we have custom handlers that call the syscall normally and then >> >> explicitly zero the return value if %edx is 1 (i.e., the child). >> >> However, >> >> in >> >> vm_fork(), we already explicitly set the value in %eax to 0 for child >> >> processes, so is this extra setting of that value in libc really needed? >> >> If >> >> not, we can safely get rid of rfork.S, vfork.S, and fork.S in libc I >> >> think. >> > >> > The thing to watch for is that the system call wrappers don't follow >> > the same conventions for call-safe registers. At least on i386 vfork >> > stashes the return address in %ecx and expects it not to be clobbered >> > by the kernel. I think all the warppers that do this use %ecx (not %edx) >> > and its the same on sparc64, %o0 and %o1 are assumed to be clobbered >> > but other otherwise non-call safe registers are assumed to be preserved. >> > So it should be ok to always clobber retval[1] by setting it to zero. >> > >> > I think you're right about fork and rfork being able to use the MIASM >> > code. rfork with RFMEM is special but it can';t be safely called from >> > C anyway. The vfork wrapper needs to stay on x86 at least because both >> > processes return to the same stack; if the retunr address is not saved in >> > a register the child may clobber the parent's when it "rets" and pops >> > the stack. >> >> Same kernel stack? The register is set in the trapframe which means it is >> saved on the kernel stack. Is that shared in the vfork case? > > Same user stack. The trapframe is copied to the child's kernel stack. Then the vfork case should be fine, b/c we fixup %eax in the child's kernel stack so that when it returns from the syscall, %eax already has the right value. -- 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 Mon Oct 29 12:12:31 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 61F8F37B401; Mon, 29 Oct 2001 12:12:25 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA29107; Mon, 29 Oct 2001 13:12:21 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id f9TKCIp00904; Mon, 29 Oct 2001 13:12:18 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15325.47137.886703.730360@caddis.yogotech.com> Date: Mon, 29 Oct 2001 13:12:17 -0700 To: tlambert2@mindspring.com Cc: Jordan Hubbard , Poul-Henning Kamp , chat@FreeBSD.ORG Subject: Re: time_t not to change size on x86 In-Reply-To: <3BDC3E88.D684676F@mindspring.com> References: <43093.1004217988@winston.freebsd.org> <3BDC3E88.D684676F@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 [ Moved to -chat, and reduced Cc list somewhat ] > > > 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. > > Any tool looks evil if it is used incorrectly. Any tool that requires you to go through the gyrations that C++ requires in order to accomplish simple things is evil. ;) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 12:21: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from p3.locore.ca (p3.locore.ca [198.96.117.171]) by hub.freebsd.org (Postfix) with ESMTP id D2BC137B407; Mon, 29 Oct 2001 12:21:05 -0800 (PST) Received: (from jake@localhost) by p3.locore.ca (8.11.4/8.11.4) id f9TKJCM39381; Mon, 29 Oct 2001 15:19:12 -0500 (EST) (envelope-from jake) Date: Mon, 29 Oct 2001 15:19:12 -0500 From: Jake Burkholder To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: syscall() ABI questions Message-ID: <20011029151912.D14748@locore.ca> References: <20011029145458.C14748@locore.ca> 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 Mon, Oct 29, 2001 at 11:59:01AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Mon, Oct 29, 2001 at 11:59:01AM -0800, John Baldwin said words to the effect of; [...] > >> > > >> > I think you're right about fork and rfork being able to use the MIASM > >> > code. rfork with RFMEM is special but it can';t be safely called from > >> > C anyway. The vfork wrapper needs to stay on x86 at least because both > >> > processes return to the same stack; if the retunr address is not saved in > >> > a register the child may clobber the parent's when it "rets" and pops > >> > the stack. > >> > >> Same kernel stack? The register is set in the trapframe which means it is > >> saved on the kernel stack. Is that shared in the vfork case? > > > > Same user stack. The trapframe is copied to the child's kernel stack. > > Then the vfork case should be fine, b/c we fixup %eax in the child's kernel > stack so that when it returns from the syscall, %eax already has the right > value. Sorry, maybe I wasn;t clear. The problem is that the parent's return address can get clobbered unless its saved in a register and copied through the trapframe. Otherwise if the child returns from the kernel and immediately executes a "ret", the parent's return address will be below %esp on the shared stack and could get clobbered. It uses jmp *%ecx now to return, which works fine because both parent and child have a _copy_ of the value. I hope this makes sense :) > > -- > > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 12:23:18 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 6873B37B401 for ; Mon, 29 Oct 2001 12:23:07 -0800 (PST) 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 f9TKMaB44949; Mon, 29 Oct 2001 15:22:36 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 29 Oct 2001 15:22:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Lyndon Nerenberg Cc: Giorgos Keramidas , arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks In-Reply-To: <200110291955.f9TJt40H005077@atg.aciworldwide.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 Mon, 29 Oct 2001, Lyndon Nerenberg wrote: > >>>>> "Giorgos" == Giorgos Keramidas writes: > > Giorgos> In that case, I stand corrected :) If the default will be > Giorgos> to still make a link cc -> gcc (and all their friends, > Giorgos> like c++, etc), then this does not soundn like a bad > Giorgos> idea. Not bad at all. > > Just to clarify, I am not proposing that /usr/bin/c{c,++} be > changed in any way. What I'm proposing is (example only): > > > --- /usr/src/gnu/usr.bin/cc/cc/Makefile 2001/10/29 19:35:26 1.1 > +++ Makefile 2001/10/29 19:40:03 > @@ -5,11 +5,14 @@ > .PATH: ${GCCDIR} > > PROG= cc > -MAN= gcc.1 > +MAN= cc.1 This seems wrong to me. The man page I get when I look at the current cc man page is clearly the man page for gcc. In my view, it should really be: PROG= gcc MAN= gcc.1 .if defined(GCC_IS_CC) MLINKS= cc.1 SYMLINKS= cc .endif But that could just be me. > SRCS= gcc.c gccspec.c > > +.if !defined(NO_GNU_NAMES) > LINKS= ${BINDIR}/cc ${BINDIR}/gcc > -MLINKS= gcc.1 cc.1 gcc.1 c++.1 gcc.1 g++.1 gcc.1 CC.1 > +MLINKS= cc.1 gcc.1 cc.1 g++.1 > +.endif > +MLINKS+= cc.1 CC.1 cc.1 c++.1 > > CFLAGS+= -DDEFAULT_TARGET_VERSION=\"$(version)\" > CFLAGS+= -DDEFAULT_TARGET_MACHINE=\"$(target)\" > > > NO_GNU_NAMES=true simply disables the creation of links to the > "GNUish" name variants where the GNU tool is installed as part of the > base system This appears to only affect the gcc and g++ commands. This seems backwards. The GNU tools should be installed with the GNU names. Installing as "cc" and "cc.1" should be the optional bit, as you might want to install an alternative compiler with those names, but retain gcc since that's what the system is designed to build with. The option name should be GNU_CC_NOT_CC or the like. > A couple of people have mentioned that the gcc name has become a defacto > standard, so we should just live with it. I don't think that's true. > I've run stable for ages without these links, and the only breakage was > in a couple of ports, and even those have since been fixed. A more > important reason for removing the links is to help with application > portability. If you're using FreeBSD as a primary development platform > for portable applications, not having gratuitous GNUisms (be they names, > or things like awk extensions) makes life easier. Generally, my thoughts on this seem to be contrary to yours. "cc" in my mind is the name of the default C compiler to use on a system. gcc is an instance of a C compiler. If I use "cc" in a Makefile, I want the system's default compiler, be it gcc or another. If I use "gcc" in a Makefile, I want to us the GNU C compiler. Interestingly, this is how it's done on the local Linux box, but not on FreeBSD: FreeBSD 5.0: ls -l `which cc` `which gcc` -r-xr-xr-x 2 root wheel 131524 Oct 23 17:21 /usr/bin/cc* -r-xr-xr-x 2 root wheel 131524 Oct 23 17:21 /usr/bin/gcc* Redhat 7.1: ls -l `which cc` `which gcc` lrwxrwxrwx 1 root root 3 Aug 7 11:37 /usr/bin/cc -> gcc* -rwxr-xr-x 2 root root 79196 Apr 5 2001 /usr/bin/gcc* 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 Mon Oct 29 12:43:12 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 2B3D137B40D; Mon, 29 Oct 2001 12:42:57 -0800 (PST) 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 f9TKgu0H005799; Mon, 29 Oct 2001 13:42:56 -0700 (MST) Message-Id: <200110292042.f9TKgu0H005799@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks In-Reply-To: Message from Robert Watson of "Mon, 29 Oct 2001 15:22:35 EST." Date: Mon, 29 Oct 2001 13:42:56 -0700 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 > This seems wrong to me. The man page I get when I look at the current > cc man page is clearly the man page for gcc. No, it's the manpage for cc. The fact that you get a manual page that corresponds to the GNU C compiler is purely an implementation artifact. (The fact that the title and command name references in the formatted manpage refer to "gcc" is a bug, IMO.) > This seems backwards. The GNU tools should be installed with the GNU > names. Installing as "cc" and "cc.1" should be the optional bit, as you > might want to install an alternative compiler with those names, but retain > gcc since that's what the system is designed to build with. No, the system is designed to be built with cc. Again, the fact that cc happens to be the GNU compiler on FreeBSD is an implementation artifact. The canonical command name for the system C compiler is still cc. Compiler implementations can change (witness Ultrix/Digital UNIX and the introduction of the MIPSco compilers) however the name stays the same. Without standard naming the system would be impossible to use, since you would have no idea what the names of any of the commands might be. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 13: 0:23 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 57C0837B406; Mon, 29 Oct 2001 13:00:20 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27026; Mon, 29 Oct 2001 12:58:22 -0800 (PST) Date: Mon, 29 Oct 2001 12:58:20 -0800 (PST) From: Julian Elischer To: Jake Burkholder Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: syscall() ABI questions In-Reply-To: <20011029151912.D14748@locore.ca> 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 But the API for vfork forbids the child from doing a 'ret' after the vfork returns.. if it does that, all bets are off.... you can do: vfork(); exec(); and that 's about all that's ok... I'm not even sure about vfork(); exit(); On Mon, 29 Oct 2001, Jake Burkholder wrote: > Apparently, On Mon, Oct 29, 2001 at 11:59:01AM -0800, > John Baldwin said words to the effect of; > > [...] > > > >> > > > >> > I think you're right about fork and rfork being able to use the MIASM > > >> > code. rfork with RFMEM is special but it can';t be safely called from > > >> > C anyway. The vfork wrapper needs to stay on x86 at least because both > > >> > processes return to the same stack; if the retunr address is not saved in > > >> > a register the child may clobber the parent's when it "rets" and pops > > >> > the stack. > > >> > > >> Same kernel stack? The register is set in the trapframe which means it is > > >> saved on the kernel stack. Is that shared in the vfork case? > > > > > > Same user stack. The trapframe is copied to the child's kernel stack. > > > > Then the vfork case should be fine, b/c we fixup %eax in the child's kernel > > stack so that when it returns from the syscall, %eax already has the right > > value. > > Sorry, maybe I wasn;t clear. The problem is that the parent's return > address can get clobbered unless its saved in a register and copied > through the trapframe. Otherwise if the child returns from the kernel > and immediately executes a "ret", the parent's return address will be > below %esp on the shared stack and could get clobbered. It uses > jmp *%ecx now to return, which works fine because both parent and > child have a _copy_ of the value. > > I hope this makes sense :) > > > > > -- > > > > 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 > > 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 Mon Oct 29 13: 0:44 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 28C5C37B401 for ; Mon, 29 Oct 2001 13:00:39 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27006; Mon, 29 Oct 2001 12:46:34 -0800 (PST) Date: Mon, 29 Oct 2001 12:46:32 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <15325.41600.832823.952280@caddis.yogotech.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 why? On Mon, 29 Oct 2001, Nate Williams wrote: > > yes you are right here.. > > > > But the two TOP bits of the nanosecond fields > > are by definition always 0 > > (you can only have up to 1,000,000,000 nano seconds in a partial second) > > and 32 bits goes up to 4(American)billion, so the two top bits can safely > > be used for multiplying the seconds scale by 4. (in UFS timestamps.. > > you would never write a non-normalised time to disk) > > also timestamps can't be before 1970 so making it unsigned > > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. > > All I can say is *yuck*. > > > > Nate > > > > > >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.... > > > > > > Simply not true. We have pico second resolution in our product, which > > > is necessary because we're using *really* fast transports, and need to > > > do very precise timing. > > > > > > (We're not using FreeBSD now, but if we need that kind of resolution in > > > 2001, I can easily see the need for much higher resolution in the > > > future.) > > > > > > I'm with PHK here (can you believe it?). :) :) > > > > > > > > > Nate > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 13: 0:57 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 C594737B407 for ; Mon, 29 Oct 2001 13:00:51 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27008; Mon, 29 Oct 2001 12:47:27 -0800 (PST) Date: Mon, 29 Oct 2001 12:47:27 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: Nate Williams , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011030065641.B13960-100000@delplex.bde.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 and you really want us to believe that data file came form 1910? On Tue, 30 Oct 2001, Bruce Evans wrote: > On Mon, 29 Oct 2001, Julian Elischer wrote: > > > be used for multiplying the seconds scale by 4. (in UFS timestamps.. > > you would never write a non-normalised time to disk) > > also timestamps can't be before 1970 so making it unsigned > > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. > > Script started on Tue Oct 30 06:55:55 2001 > ttyp1:bde@gamplex:/tmp> touch -t 191001011230 foo > ttyp1:bde@gamplex:/tmp> ls -l foo > -rw-r--r-- 1 bde wheel 0 Jan 1 1910 foo > ttyp1:bde@gamplex:/tmp> exit > > Script done on Tue Oct 30 06:56:10 2001 > > Bruce > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 13: 2:35 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 C062837B403 for ; Mon, 29 Oct 2001 13:02:26 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA01165; Mon, 29 Oct 2001 14:02:19 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id f9TL2JR02596; Mon, 29 Oct 2001 14:02:19 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15325.50138.784256.957313@caddis.yogotech.com> Date: Mon, 29 Oct 2001 14:02:18 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: References: <15325.41600.832823.952280@caddis.yogotech.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 > why? Stealing bits means that folks will end up having to roll their own time-handling code, and is just a hack. Been there, done that, will avoid any solution that does it again. :( Nate > On Mon, 29 Oct 2001, Nate Williams wrote: > > > > yes you are right here.. > > > > > > But the two TOP bits of the nanosecond fields > > > are by definition always 0 > > > (you can only have up to 1,000,000,000 nano seconds in a partial second) > > > and 32 bits goes up to 4(American)billion, so the two top bits can safely > > > be used for multiplying the seconds scale by 4. (in UFS timestamps.. > > > you would never write a non-normalised time to disk) > > > also timestamps can't be before 1970 so making it unsigned > > > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. > > > > All I can say is *yuck*. > > > > > > > > Nate > > > > > > > >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.... > > > > > > > > Simply not true. We have pico second resolution in our product, which > > > > is necessary because we're using *really* fast transports, and need to > > > > do very precise timing. > > > > > > > > (We're not using FreeBSD now, but if we need that kind of resolution in > > > > 2001, I can easily see the need for much higher resolution in the > > > > future.) > > > > > > > > I'm with PHK here (can you believe it?). :) :) > > > > > > > > > > > > Nate > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 13:31:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 1F9B437B405; Mon, 29 Oct 2001 13:31:54 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 15yK0e-000DpQ-0U; Mon, 29 Oct 2001 21:31:52 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9TLUb765618; Mon, 29 Oct 2001 21:30:37 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 29 Oct 2001 21:30:37 +0000 (GMT) From: Doug Rabson To: Julian Elischer Cc: Jake Burkholder , John Baldwin , Subject: Re: syscall() ABI questions In-Reply-To: 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, 29 Oct 2001, Julian Elischer wrote: > But the API for vfork forbids the child from doing a 'ret' after the vfork > returns.. if it does that, all bets are off.... you can do: > vfork(); > exec(); > > and that 's about all that's ok... > I'm not even sure about > vfork(); > exit(); I think the point is that the vfork stub has to return back to the function which is intending to call exec() and therefore exposes the memory location which held the return address to possible corruption (certain corruption considering that the call to exec will push stuff onto the stack). -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 13:40:52 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 E36CE37B401 for ; Mon, 29 Oct 2001 13:40:50 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9TLehw15955; Mon, 29 Oct 2001 16:40:43 -0500 (EST) (envelope-from wollman) Date: Mon, 29 Oct 2001 16:40:43 -0500 (EST) From: Garrett Wollman Message-Id: <200110292140.f9TLehw15955@khavrinen.lcs.mit.edu> To: julian@elischer.org Subject: Re: syscall() ABI questions In-Reply-To: References: <20011029151912.D14748@locore.ca> 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: >But the API for vfork forbids the child from doing a 'ret' after the vfork >returns.. if it does that, all bets are off.... you can do: vfork() in general doesn't work. The fact that it works on current FreeBSD platforms is just a coincidence. (It's effectively switching to a different stack in the child, which happens to be located in the same place as the existing stack. If there were a real alternate stack, vfork() would at least have a chance at being reliable, but this is impossible in the general case without help from the compiler.) IWBRNI we could implement the brand-spankin'-new posix_spawn() interface, which attempts to provide the benefits of vfork (in its normal usage pattern) without making assumptions about stack usage. -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 Mon Oct 29 13:42:39 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 1524A37B406 for ; Mon, 29 Oct 2001 13:42:34 -0800 (PST) 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 f9TLgMB46558; Mon, 29 Oct 2001 16:42:22 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 29 Oct 2001 16:42:21 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Lyndon Nerenberg Cc: arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks In-Reply-To: <200110292042.f9TKgu0H005799@atg.aciworldwide.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 Mon, 29 Oct 2001, Lyndon Nerenberg wrote: > > This seems wrong to me. The man page I get when I look at the current > > cc man page is clearly the man page for gcc. > > No, it's the manpage for cc. The fact that you get a manual page that > corresponds to the GNU C compiler is purely an implementation artifact. > (The fact that the title and command name references in the formatted > manpage refer to "gcc" is a bug, IMO.) Are you sure? /usr/share/man/man1/cc.1.gz: .\" $FreeBSD: src/contrib/gcc.295/gcc.1,v 1.16 2001/08/01 18:35:54 obrien Exp $ .\" Copyright (c) 1991, 1992, 1993, 1994 Free Software Foundation -*-Text-*- .\" See section COPYING for conditions for redistribution And... The information in this man page is an extract from the full documentation of the GNU C compiler, and is limited to the meaning of the options. It documents GNU-specific CC command-line options later in the man page, as far as I can tell, anyway. > > This seems backwards. The GNU tools should be installed with the GNU > > names. Installing as "cc" and "cc.1" should be the optional bit, as you > > might want to install an alternative compiler with those names, but retain > > gcc since that's what the system is designed to build with. > > No, the system is designed to be built with cc. Again, the fact that cc > happens to be the GNU compiler on FreeBSD is an implementation artifact. > The canonical command name for the system C compiler is still cc. > Compiler implementations can change (witness Ultrix/Digital UNIX and the > introduction of the MIPSco compilers) however the name stays the same. > Without standard naming the system would be impossible to use, since you > would have no idea what the names of any of the commands might be. You appear to be misunderstanding what I'm suggesting. I'm not saying that cc shouldn't point as gcc, I'm saying that gcc should be gcc, and cc should be a pointer that can be directed at the administrator's choice of cc's, which by default would be gcc. I don't see that removing the 'g' from gcc accomplishes anything: in fact, it attempts to obfuscate that fact that cc really is gcc, and it serves the purpose of creating naming conflicts in the event that another cc becomes available. Look at how we addresses the MTA issue. Also, contrary to what you're suggesting, the system is designed to be built with the GNU C compiler. We have gcc'isms in a number of places in the source tree, and the chances are very high that the system would not work properly unless the compiler perfectly emulated these gcc-isms. We also ship (and test) only with the GNU C compiler. Arguably, we should support other C compilers, if any decent ones existed. 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 Mon Oct 29 13:44: 4 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 3C4DF37B405 for ; Mon, 29 Oct 2001 13:44:00 -0800 (PST) Received: (qmail 30085 invoked from network); 29 Oct 2001 21:43:59 -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 ; 29 Oct 2001 21:43:59 -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: <20011029151912.D14748@locore.ca> Date: Mon, 29 Oct 2001 13:43:48 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: Re: syscall() ABI questions 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 On 29-Oct-01 Jake Burkholder wrote: > Apparently, On Mon, Oct 29, 2001 at 11:59:01AM -0800, > John Baldwin said words to the effect of; > > [...] > >> >> > >> >> > I think you're right about fork and rfork being able to use the MIASM >> >> > code. rfork with RFMEM is special but it can';t be safely called from >> >> > C anyway. The vfork wrapper needs to stay on x86 at least because both >> >> > processes return to the same stack; if the retunr address is not saved >> >> > in >> >> > a register the child may clobber the parent's when it "rets" and pops >> >> > the stack. >> >> >> >> Same kernel stack? The register is set in the trapframe which means it >> >> is >> >> saved on the kernel stack. Is that shared in the vfork case? >> > >> > Same user stack. The trapframe is copied to the child's kernel stack. >> >> Then the vfork case should be fine, b/c we fixup %eax in the child's kernel >> stack so that when it returns from the syscall, %eax already has the right >> value. > > Sorry, maybe I wasn;t clear. The problem is that the parent's return > address can get clobbered unless its saved in a register and copied > through the trapframe. Otherwise if the child returns from the kernel > and immediately executes a "ret", the parent's return address will be > below %esp on the shared stack and could get clobbered. It uses > jmp *%ecx now to return, which works fine because both parent and > child have a _copy_ of the value. > > I hope this makes sense :) Oh, doh, yes. For some reason I had forgotten vfork had more to it than fork does. I amend to mean that we remove the setting of %eax which means fork and rfork go back to being standard (aside from the rfork_thread() case to handle RFMEM) -- 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 Mon Oct 29 13:44:15 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 5C34437B405 for ; Mon, 29 Oct 2001 13:44:05 -0800 (PST) Received: (qmail 96698 invoked from network); 29 Oct 2001 21:44:04 -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 ; 29 Oct 2001 21:44:04 -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: Mon, 29 Oct 2001 13:43:53 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: syscall() ABI questions Cc: arch@FreeBSD.ORG, Jake Burkholder Sender: owner-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 29-Oct-01 Julian Elischer wrote: > But the API for vfork forbids the child from doing a 'ret' after the vfork > returns.. if it does that, all bets are off.... you can do: > vfork(); > exec(); > > and that 's about all that's ok... > I'm not even sure about > vfork(); > exit(); Jake is talking about the return from the actual vfork() wrapper in libc for the syscall. We have to return from that. :) So we do that by saving the return address in a register and adjusting the stack before return in case the child clobbers that part of the stack we can restore it for the parent. -- 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 Mon Oct 29 14:10:19 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 027D637B403 for ; Mon, 29 Oct 2001 14:10:16 -0800 (PST) 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 f9TMA6f38454; Mon, 29 Oct 2001 17:10:06 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Mon, 29 Oct 2001 17:10:03 -0500 To: Julian Elischer , Nate Williams 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 At 12:46 PM -0800 10/29/01, Julian Elischer wrote: >why? You are coming up with a method to expand timestamps to the year 2600, and the proposal works by stealing bits from one place and adding that to unsigned bits in another. I can not imagine 400 years of looking at such a baroque kludge, so I also say "yuck". We can fix time_t to hold 64-bit values. Kirk McKusick has already said that he's working on an upgrade for UFS which will simply store those 64-bit values as 64-bit values. I would rather see energy spent on that solution instead of piecing together a value from various bits which are theoretically available. If we get so UFS2 has basically replaced UFS by (say) 2010, then we'll be in fine shape and in plenty of time. That is just my opinion, of course. >On Mon, 29 Oct 2001, Nate Williams wrote: > >> > yes you are right here.. >> > > > > But the two TOP bits of the nanosecond fields are by definition > > > always 0 (you can only have up to 1,000,000,000 nano seconds in > > > a partial second) and 32 bits goes up to 4 (American)billion, so > > > the two top bits can safely be used for multiplying the seconds > > > scale by 4. ... timestamps can't be before 1970 so making it > > > unsigned allows us to go to 2100+ and mutiplying it by four takes > > > us to about 2600.. > > > > All I can say is *yuck*. -- 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 Mon Oct 29 14:16:41 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 14D5337B401; Mon, 29 Oct 2001 14:16:39 -0800 (PST) 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 f9TMGc0H006478; Mon, 29 Oct 2001 15:16:38 -0700 (MST) Message-Id: <200110292216.f9TMGc0H006478@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks In-Reply-To: Message from Robert Watson of "Mon, 29 Oct 2001 16:42:21 EST." Date: Mon, 29 Oct 2001 15:16:38 -0700 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 > Also, contrary to what you're suggesting, the system is designed to be > built with the GNU C compiler. We have gcc'isms in a number of places in > the source tree, and the chances are very high that the system would not > work properly unless the compiler perfectly emulated these gcc-isms. Sure, but I can make the same argument about Irix and the MIPSpro compilers. Or Solaris and the Sparcworks compilers. Neither of these OSes find it necessary to use names other than cc. What are the chances, realistically, that FreeBSD will ever ship with two C compilers in the base system? --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 15:21:54 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 E407437B401; Mon, 29 Oct 2001 15:21:51 -0800 (PST) Received: from hades.hell.gr (patr530-a142.otenet.gr [212.205.215.142]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f9TNLk812841; Tue, 30 Oct 2001 01:21:46 +0200 (EET) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f9TNLiC32913; Tue, 30 Oct 2001 01:21:44 +0200 (EET) (envelope-from charon@labs.gr) Date: Tue, 30 Oct 2001 01:21:43 +0200 From: Giorgos Keramidas To: Lyndon Nerenberg Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks Message-ID: <20011030012143.B32738@hades.hell.gr> References: <200110292216.f9TMGc0H006478@atg.aciworldwide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110292216.f9TMGc0H006478@atg.aciworldwide.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 Mon, Oct 29, 2001 at 03:16:38PM -0700, Lyndon Nerenberg wrote: > > What are the chances, realistically, that FreeBSD will ever ship > with two C compilers in the base system? Well, Lyndon, this is quickly turning into a flamefest. Despite the fact that it's no big deal, really. The system compiler in all Unixen is called `cc', and in FreeBSD one cann depend to find the system compiler called `cc'. It so happens that our system compiler is the GNU C Compiler, and the GNU'ism of calling it gcc is not *that* bad. I mean come on, all this arguments coming and going to and for, for a couple or so of hard links? It really is not worth it, is it? -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 29 16:52: 5 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 7558537B405 for ; Mon, 29 Oct 2001 16:51:52 -0800 (PST) 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 f9U0pqM59868 for ; Mon, 29 Oct 2001 16:51:52 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id CD997380A; Mon, 29 Oct 2001 16:51:51 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garance A Drosihn Cc: Julian Elischer , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Date: Mon, 29 Oct 2001 16:51:51 -0800 From: Peter Wemm Message-Id: <20011030005151.CD997380A@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 Garance A Drosihn wrote: > At 12:46 PM -0800 10/29/01, Julian Elischer wrote: > >why? > > You are coming up with a method to expand timestamps to the year > 2600, and the proposal works by stealing bits from one place and > adding that to unsigned bits in another. I can not imagine 400 > years of looking at such a baroque kludge, so I also say "yuck". > > We can fix time_t to hold 64-bit values. Kirk McKusick has already > said that he's working on an upgrade for UFS which will simply store > those 64-bit values as 64-bit values. I would rather see energy > spent on that solution instead of piecing together a value from > various bits which are theoretically available. If we get so UFS2 > has basically replaced UFS by (say) 2010, then we'll be in fine > shape and in plenty of time. > > That is just my opinion, of course. And it is quite valid. There is NO NEED to tweak UFS for timestamps. It will be good right up till 2038 if we're still using it instead of UFS2 or UFS3 or whatever. UFS does not have future dates and does not do future date calculations. We could probably even change the ufs_time_t to unsigned and string it out to 2106 or so if we really wanted to stretch it out beyond reason. Repeat: there is no point "fixing" the ufs timestamps. UFS2 will take care of it. > >On Mon, 29 Oct 2001, Nate Williams wrote: > > > >> > yes you are right here.. > >> > > > > > But the two TOP bits of the nanosecond fields are by definition > > > > always 0 (you can only have up to 1,000,000,000 nano seconds in > > > > a partial second) and 32 bits goes up to 4 (American)billion, so > > > > the two top bits can safely be used for multiplying the seconds > > > > scale by 4. ... timestamps can't be before 1970 so making it > > > > unsigned allows us to go to 2100+ and mutiplying it by four takes > > > > us to about 2600.. > > > > > > All I can say is *yuck*. > > -- > 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 > > 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 Mon Oct 29 20:42:36 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 8289237B40A for ; Mon, 29 Oct 2001 20:42:29 -0800 (PST) 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 f9U4gMV02304 for ; Mon, 29 Oct 2001 21:42:22 -0700 (MST) (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 f9U4gM701469 for ; Mon, 29 Oct 2001 21:42:22 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200110300442.f9U4gM701469@harmony.village.org> To: arch@freebsd.org Subject: Makefile unification Date: Mon, 29 Oct 2001 21:42:22 -0700 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 I took some time out to update my Makefiles and redo my kern.mk patches that had gotten out of date before I could get them done. These patches are up to date and appear to work for me on i386 (and maybe pc98, it is building now): http://people.freebsd.org/~imp/Pkern It creates a new src/sys/conf/kern.mk that contains most of the guts of the kernel makefiles to make it even easier to keep them all in sync. Please let me know what you think and if I've broken anything, especially for non x86 MACHINE_ARCH. 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 29 20:54:31 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 C47DD37B401; Mon, 29 Oct 2001 20:54:25 -0800 (PST) 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 f9U4sNV02372; Mon, 29 Oct 2001 21:54:23 -0700 (MST) (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 f9U4sK701614; Mon, 29 Oct 2001 21:54:20 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200110300454.f9U4sK701614@harmony.village.org> To: nate@yogotech.com (Nate Williams) Subject: Re: ACPI: APM compatibility implementation Cc: tlambert2@mindspring.com, Mitsuru IWASAKI , acpi-jp@jp.FreeBSD.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG In-reply-to: Your message of "Thu, 25 Oct 2001 14:31:48 MDT." <15320.30388.178781.313461@caddis.yogotech.com> References: <15320.30388.178781.313461@caddis.yogotech.com> <20011025.012243.71082514.iwasaki@jp.FreeBSD.org> <3BD8327C.A73CF24A@mindspring.com> Date: Mon, 29 Oct 2001 21:54:20 -0700 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 <15320.30388.178781.313461@caddis.yogotech.com> Nate Williams writes: : 3+ hours is actually common on even newer hardware. 10:52pm hammer:[72]> apm APM version: 1.2 APM Managment: Enabled AC Line status: on-line Battery status: charging Remaining battery life: 69% Remaining battery time: 8:01:00 Number of batteries: 2 Battery 0: Battery status: charging Remaining battery life: 57% Remaining battery time: 3:19:00 Battery 1: Battery status: charging Remaining battery life: 81% Remaining battery time: 4:42:00 APM Capacities: global suspend state resume timer from suspend This is on my Inspiron 8000, which is a big boat of a laptop. I usually get about 8 hours of time (or about 65% of what I'm normally told). 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 29 21: 8: 9 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 1CE8B37B403; Mon, 29 Oct 2001 21:08:08 -0800 (PST) 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 f9U587p12661; Mon, 29 Oct 2001 21:08:07 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9U589p01072; Mon, 29 Oct 2001 21:08:09 -0800 (PST) (envelope-from marcel) Date: Mon, 29 Oct 2001 21:08:08 -0800 From: Marcel Moolenaar To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: syscall() ABI questions Message-ID: <20011029210808.A1009@dhcp01.pn.xcllnt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Oct 29, 2001 at 02:16:37AM -0800, John Baldwin wrote: > I've got some questions about td->td_retval[1] and our syscall ABI. On some > archs (ia64, alpha) we preinitialie this value to 0. On other archs (i386, > sparc64, ppc) we set it to the value of the register it will be set to so that > effectively this register's value is preserved across the syscall. My question > is do our syscall ABI's actually assume that for syscalls with only one return > value that register isn't written to? NetBSD recently changed their i386 > syscall code to preinitialize to 0 rather than %edx. Anyone have the history > on this? I don't have the history, but I do know that Linux assumes %edx is preserved. We may want to keep that in mind if for Linuxulator's sake. FYI, -- 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 Mon Oct 29 21: 9:32 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 D328637B401 for ; Mon, 29 Oct 2001 21:09:28 -0800 (PST) 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 f9U59RV02463; Mon, 29 Oct 2001 22:09:27 -0700 (MST) (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 f9U59Q701756; Mon, 29 Oct 2001 22:09:26 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200110300509.f9U59Q701756@harmony.village.org> To: Poul-Henning Kamp Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 27 Oct 2001 00:20:52 +0200." <613.1004134852@critter.freebsd.dk> References: <613.1004134852@critter.freebsd.dk> Date: Mon, 29 Oct 2001 22:09:26 -0700 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 <613.1004134852@critter.freebsd.dk> Poul-Henning Kamp writes: : 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 :-) Xtals in PCs SUCKSUCKSUCKSUCK. They are accurate to a factor of 1E-8 or so. This is >> 1/(2^64). When something drifts a second or two a day (or even a week or a month), you know it is really bad. 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 29 21:26:32 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 9A49237B403 for ; Mon, 29 Oct 2001 21:26:29 -0800 (PST) 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 f9U5QSV02539 for ; Mon, 29 Oct 2001 22:26:28 -0700 (MST) (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 f9U5QR701909 for ; Mon, 29 Oct 2001 22:26:27 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200110300526.f9U5QR701909@harmony.village.org> Subject: Re: 64 bit times revisited.. To: arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 29 Oct 2001 22:09:26 MST." <200110300509.f9U59Q701756@harmony.village.org> References: <200110300509.f9U59Q701756@harmony.village.org> <613.1004134852@critter.freebsd.dk> Date: Mon, 29 Oct 2001 22:26:27 -0700 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 <200110300509.f9U59Q701756@harmony.village.org> Warner Losh writes: : Xtals in PCs SUCKSUCKSUCKSUCK. They are accurate to a factor of 1E-8 : or so. This is >> 1/(2^64). When something drifts a second or two a : day (or even a week or a month), you know it is really bad. I forgot the punchline: The error from the variance in your xtal is so far going to swamp the error from rounding for 1/(2^64) that it isn't a reason to not do it. After reading the thread, people seem to be under the impression that the xtals in PCs are consistant or stable. They are neither by any stretch of the imagination. There may be other reasons to not do this, but this isn't one. :-) 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 29 22:58:54 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 CEFA037B406 for ; Mon, 29 Oct 2001 22:58:51 -0800 (PST) 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 f9U6woV03002 for ; Mon, 29 Oct 2001 23:58:50 -0700 (MST) (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 f9U6wn725693 for ; Mon, 29 Oct 2001 23:58:49 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200110300658.f9U6wn725693@harmony.village.org> Subject: Re: Makefile unification To: arch@freebsd.org Date: Mon, 29 Oct 2001 23:58:49 -0700 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 Warner Losh writes: : I took some time out to update my Makefiles and redo my kern.mk : patches that had gotten out of date before I could get them done. : These patches are up to date and appear to work for me on i386 (and : maybe pc98, it is building now): : : http://people.freebsd.org/~imp/Pkern : : It creates a new src/sys/conf/kern.mk that contains most of the guts : of the kernel makefiles to make it even easier to keep them all in : sync. Actaully, I updated the above. It turns out my first attempt didn't work after make clean blew away my _if.h files. So now I have a kern1.mk and kern2.mk, one at the beginning, and one at the end to properly deal with things. 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 29 23: 6:32 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 6D36F37B403 for ; Mon, 29 Oct 2001 23:06:29 -0800 (PST) Received: (qmail 30093 invoked from network); 30 Oct 2001 07:06:23 -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 ; 30 Oct 2001 07:06:23 -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: <200110300658.f9U6wn725693@harmony.village.org> Date: Mon, 29 Oct 2001 23:06:09 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: Makefile unification 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 On 30-Oct-01 Warner Losh wrote: > Warner Losh writes: >: I took some time out to update my Makefiles and redo my kern.mk >: patches that had gotten out of date before I could get them done. >: These patches are up to date and appear to work for me on i386 (and >: maybe pc98, it is building now): >: >: http://people.freebsd.org/~imp/Pkern >: >: It creates a new src/sys/conf/kern.mk that contains most of the guts >: of the kernel makefiles to make it even easier to keep them all in >: sync. > > Actaully, I updated the above. It turns out my first attempt didn't work > after make clean blew away my _if.h files. > > So now I have a kern1.mk and kern2.mk, one at the beginning, and one > at the end to properly deal with things. Maybe kern.pre.mk and kern.post.mk to follow other naming conventions we already use? (see bsd.port.*.mk) > Warner -- 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 Mon Oct 29 23: 7:45 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 1907A37B406; Mon, 29 Oct 2001 23:07:42 -0800 (PST) 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 f9U77eV03069; Tue, 30 Oct 2001 00:07:40 -0700 (MST) (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 f9U77d725802; Tue, 30 Oct 2001 00:07:40 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200110300707.f9U77d725802@harmony.village.org> To: John Baldwin Subject: Re: Makefile unification Cc: arch@FreeBSD.org In-reply-to: Your message of "Mon, 29 Oct 2001 23:06:09 PST." References: Date: Tue, 30 Oct 2001 00:07:39 -0700 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 John Baldwin writes: : Maybe kern.pre.mk and kern.post.mk to follow other naming conventions we : already use? (see bsd.port.*.mk) OK. I like these names better. I'll change them at some point, but I won't update just yet (since I'm headed to bed right now). Any other comments? Does it work for you? 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 29 23: 9:38 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 6F7C437B401 for ; Mon, 29 Oct 2001 23:09:36 -0800 (PST) Received: (qmail 23443 invoked from network); 30 Oct 2001 07:09:35 -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 ; 30 Oct 2001 07:09:35 -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: <200110300707.f9U77d725802@harmony.village.org> Date: Mon, 29 Oct 2001 23:09:24 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: Makefile unification 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 On 30-Oct-01 Warner Losh wrote: > In message John Baldwin writes: >: Maybe kern.pre.mk and kern.post.mk to follow other naming conventions we >: already use? (see bsd.port.*.mk) > > OK. I like these names better. I'll change them at some point, but I > won't update just yet (since I'm headed to bed right now). > > Any other comments? Does it work for you? Haven't had a chance to look at them. Was off doing musical practice this evening. :) I can try them out on alpha and x86 tomorrow however. > Warner -- 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 30 2: 7:55 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 D827137B403 for ; Tue, 30 Oct 2001 02:07:52 -0800 (PST) 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 VAA03811; Tue, 30 Oct 2001 21:07:28 +1100 Date: Tue, 30 Oct 2001 21:06:27 +1100 (EST) From: Bruce Evans X-X-Sender: To: Peter Wemm Cc: Garance A Drosihn , Julian Elischer , Nate Williams , Subject: Re: 64 bit times revisited.. In-Reply-To: <20011030005151.CD997380A@overcee.netplex.com.au> Message-ID: <20011030210506.G1406-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 Mon, 29 Oct 2001, Peter Wemm wrote: > ... UFS does not have future dates ... Script started on Tue Oct 30 21:04:39 2001 ttyv7:bde@delplex:/tmp> touch -t 203801011230 foo ttyv7:bde@delplex:/tmp> ls -l foo -rw-r--r-- 1 bde wheel 0 Jan 1 2038 foo ttyv7:bde@delplex:/tmp> exit Script done on Tue Oct 30 21:05:00 2001 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 30 2:17: 4 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 AF5D137B401 for ; Tue, 30 Oct 2001 02:17:00 -0800 (PST) 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 VAA04581; Tue, 30 Oct 2001 21:16:46 +1100 Date: Tue, 30 Oct 2001 21:15:46 +1100 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , Peter Wemm , Subject: Re: 64 bit times revisited.. In-Reply-To: Message-ID: <20011030210857.R1525-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 Mon, 29 Oct 2001, Julian Elischer wrote: > and you really want us to believe that data file came form 1910? I simply refuted a false claim that timestamps can't be before 1970. > On Tue, 30 Oct 2001, Bruce Evans wrote: > > > On Mon, 29 Oct 2001, Julian Elischer wrote: > > > > > be used for multiplying the seconds scale by 4. (in UFS timestamps.. > > > you would never write a non-normalised time to disk) > > > also timestamps can't be before 1970 so making it unsigned > > > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. > > > > Script started on Tue Oct 30 06:55:55 2001 > > ttyp1:bde@gamplex:/tmp> touch -t 191001011230 foo > > ttyp1:bde@gamplex:/tmp> ls -l foo > > -rw-r--r-- 1 bde wheel 0 Jan 1 1910 foo > > ttyp1:bde@gamplex:/tmp> exit > > > > Script done on Tue Oct 30 06:56:10 2001 This mailing list is approaching the quality of the average newsgroup, complete with top posting by newbies. 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 30 8:42:11 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 A6EA237B401; Tue, 30 Oct 2001 08:36:44 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 4DF6514C2E; Tue, 30 Oct 2001 17:36:43 +0100 (CET) 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 Cc: audit@freebsd.org Subject: procfs megapatch From: Dag-Erling Smorgrav Date: 30 Oct 2001 17:36:36 +0100 Message-ID: Lines: 16 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 --=-=-= The attached patch replaces procfs with a pseudofs-based version. It is fully equivalent except for the lack of debugging support, which is intentional (I have working debugging support in my tree, and part of it is in fact included in this patch, but disabled). This means truss will not work with this patch in place. I am working on revamping ptrace and have written a new version of truss which works with ptrace instead of procfs. I will am also thinking of writing a separate module that grafts onto procfs and implements the legacy debugging interface, to cater for strace et al. DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch; charset=iso-8859-1 Content-Disposition: attachment; filename=procfs-20011030.diff Content-Transfer-Encoding: quoted-printable Index: sys/conf/files =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.576 diff -u -r1.576 files --- sys/conf/files 20 Oct 2001 18:50:31 -0000 1.576 +++ sys/conf/files 22 Oct 2001 13:01:43 -0000 @@ -640,6 +640,7 @@ fs/nwfs/nwfs_vnops.c optional nwfs fs/portalfs/portal_vfsops.c optional portalfs fs/portalfs/portal_vnops.c optional portalfs +fs/procfs/procfs.c optional procfs fs/procfs/procfs_ctl.c optional procfs fs/procfs/procfs_dbregs.c optional procfs fs/procfs/procfs_fpregs.c optional procfs @@ -649,10 +650,7 @@ fs/procfs/procfs_regs.c optional procfs fs/procfs/procfs_rlimit.c optional procfs fs/procfs/procfs_status.c optional procfs -fs/procfs/procfs_subr.c optional procfs fs/procfs/procfs_type.c optional procfs -fs/procfs/procfs_vfsops.c optional procfs -fs/procfs/procfs_vnops.c optional procfs fs/pseudofs/pseudofs.c optional pseudofs fs/pseudofs/pseudofs_fileno.c optional pseudofs fs/pseudofs/pseudofs_vncache.c optional pseudofs Index: sys/fs/procfs/procfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: sys/fs/procfs/procfs.c diff -N sys/fs/procfs/procfs.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/fs/procfs/procfs.c 30 Oct 2001 16:34:19 -0000 @@ -0,0 +1,197 @@ +/* + * Copyright (c) 2001 Dag-Erling Sm=F8rgrav + * Copyright (c) 1993 Jan-Simon Pendry + * Copyright (c) 1993 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * Jan-Simon Pendry. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)procfs_vfsops.c 8.7 (Berkeley) 5/10/95 + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include + +/* + * Filler function for proc/pid/self + */ +static int +procfs_doprocfile(PFS_FILL_ARGS) +{ + char *fullpath =3D "unknown"; + char *freepath =3D NULL; + + vn_fullpath(td, td->td_proc->p_textvp, &fullpath, &freepath); + sbuf_printf(sb, "%s", fullpath); + if (freepath) + free(freepath, M_TEMP); + return (0); +} + +/* + * Filler function for proc/curproc + */ +static int +procfs_docurproc(PFS_FILL_ARGS) +{ + sbuf_printf(sb, "%ld", (long)td->td_proc->p_pid); + return (0); +} + +/* + * Adjust mode for some nodes that need it + */ +int +procfs_attr(PFS_ATTR_ARGS) +{ + /* XXX inefficient, split into separate functions */ + if (strcmp(pn->pn_name, "ctl") =3D=3D 0 || + strcmp(pn->pn_name, "note") =3D=3D 0 || + strcmp(pn->pn_name, "notepg") =3D=3D 0) + vap->va_mode =3D 0200; + else if (strcmp(pn->pn_name, "mem") =3D=3D 0 || + strcmp(pn->pn_name, "regs") =3D=3D 0 || + strcmp(pn->pn_name, "dbregs") =3D=3D 0 || + strcmp(pn->pn_name, "fpregs") =3D=3D 0) + vap->va_mode =3D 0600; + + /* p is locked by caller */ + vap->va_uid =3D p->p_ucred->cr_uid; + vap->va_gid =3D p->p_ucred->cr_gid; +=09 + return (0); +} + +/* + * Visibility: some files only exist for non-system processes + * Non-static because linprocfs uses it. + */ +int +procfs_notsystem(PFS_VIS_ARGS) +{ + return ((p->p_flag & P_SYSTEM) =3D=3D 0); +} + +/* + * Visibility: some files are only visible to process that can debug + * the target process. + */ +int +procfs_candebug(PFS_VIS_ARGS) +{ + return ((p->p_flag & P_SYSTEM) =3D=3D 0 && + p_candebug(td->td_proc, p) =3D=3D 0); +} + +/* + * Constructor + */ +static int +procfs_init(PFS_INIT_ARGS) +{ + struct pfs_node *root; + struct pfs_node *dir; + struct pfs_node *node; + + root =3D pi->pi_root; + + pfs_create_link(root, "curproc", &procfs_docurproc, + NULL, NULL, 0); +=09 + dir =3D pfs_create_dir(root, "pid", + &procfs_attr, NULL, PFS_PROCDEP); + pfs_create_file(dir, "cmdline", &procfs_doproccmdline, + NULL, NULL, PFS_RD); +#if 0 + pfs_create_file(dir, "ctl", &procfs_doprocctl, + &procfs_attr, NULL, PFS_WR); +#endif + pfs_create_file(dir, "dbregs", &procfs_doprocdbregs, + &procfs_attr, &procfs_candebug, PFS_RDWR|PFS_RAW); + pfs_create_file(dir, "etype", &procfs_doproctype, + NULL, NULL, PFS_RD); + pfs_create_file(dir, "fpregs", &procfs_doprocfpregs, + &procfs_attr, &procfs_candebug, PFS_RDWR|PFS_RAW); + pfs_create_file(dir, "map", &procfs_doprocmap, + NULL, &procfs_notsystem, PFS_RD); + pfs_create_file(dir, "mem", &procfs_doprocmem, + &procfs_attr, &procfs_candebug, PFS_RDWR|PFS_RAW); + pfs_create_file(dir, "note", &procfs_doprocnote, + &procfs_attr, &procfs_candebug, PFS_WR); + pfs_create_file(dir, "notepg", &procfs_doprocnote, + &procfs_attr, &procfs_candebug, PFS_WR); + pfs_create_file(dir, "regs", &procfs_doprocregs, + &procfs_attr, &procfs_candebug, PFS_RDWR|PFS_RAW); + pfs_create_file(dir, "rlimit", &procfs_doprocrlimit, + NULL, NULL, PFS_RD); + pfs_create_file(dir, "status", &procfs_doprocstatus, + NULL, NULL, PFS_RD); +=09 + pfs_create_link(dir, "file", &procfs_doprocfile, + NULL, procfs_notsystem, 0); +=09 + return (0); +} + +/* + * Destructor + */ +static int +procfs_uninit(PFS_INIT_ARGS) +{ + + /* nothing to do, pseudofs will GC */ + return (0); +} + +PSEUDOFS(procfs, 1); Index: sys/fs/procfs/procfs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs.h,v retrieving revision 1.39 diff -u -r1.39 procfs.h --- sys/fs/procfs/procfs.h 7 Oct 2001 20:08:37 -0000 1.39 +++ sys/fs/procfs/procfs.h 12 Oct 2001 13:11:03 -0000 @@ -40,109 +40,28 @@ * $FreeBSD: src/sys/fs/procfs/procfs.h,v 1.39 2001/10/07 20:08:37 des Exp= $ */ =20 -/* - * The different types of node in a procfs filesystem - */ -typedef enum { - Proot, /* the filesystem root */ - Pcurproc, /* symbolic link for curproc */ - Pproc, /* a process-specific sub-directory */ - Pfile, /* the executable file */ - Pmem, /* the process's memory image */ - Pregs, /* the process's register set */ - Pfpregs, /* the process's FP register set */ - Pdbregs, /* the process's debug register set */ - Pctl, /* process control */ - Pstatus, /* process status */ - Pnote, /* process notifier */ - Pnotepg, /* process group notifier */ - Pmap, /* memory map */ - Ptype, /* executable type */ - Pcmdline, /* command line */ - Prlimit /* resource limits */ -} pfstype; - -/* - * control data for the proc file system. - */ -struct pfsnode { - struct pfsnode *pfs_next; /* next on list */ - struct vnode *pfs_vnode; /* vnode associated with this pfsnode */ - pfstype pfs_type; /* type of procfs node */ - pid_t pfs_pid; /* associated process */ - u_short pfs_mode; /* mode bits for stat() */ - u_long pfs_flags; /* open flags */ - u_long pfs_fileno; /* unique file id */ - pid_t pfs_lockowner; /* pfs lock owner */ -}; - -#define PROCFS_NOTELEN 64 /* max length of a note (/proc/$pid/note) */ -#define PROCFS_CTLLEN 8 /* max length of a ctl msg (/proc/$pid/ctl */ -#define PROCFS_NAMELEN 8 /* max length of a filename component */ - -/* - * Kernel stuff follows - */ #ifdef _KERNEL -#define CNEQ(cnp, s, len) \ - ((cnp)->cn_namelen =3D=3D (len) && \ - (bcmp((s), (cnp)->cn_nameptr, (len)) =3D=3D 0)) - -#define PROCFS_FILENO(pid, type) \ - (((type) < Pproc) ? \ - ((type) + 2) : \ - ((((pid)+1) << 4) + ((int) (type)))) - -/* - * Convert between pfsnode vnode - */ -#define VTOPFS(vp) ((struct pfsnode *)(vp)->v_data) -#define PFSTOV(pfs) ((pfs)->pfs_vnode) - -typedef struct vfs_namemap vfs_namemap_t; -struct vfs_namemap { - const char *nm_name; - int nm_val; -}; - -int vfs_getuserstr __P((struct uio *, char *, int *)); -vfs_namemap_t *vfs_findname __P((vfs_namemap_t *, char *, int)); - -/* */ -struct reg; -struct fpreg; -struct dbreg; - -#define PFIND(pid) (pfind(pid)) - -void procfs_exit __P((struct proc *)); -int procfs_freevp __P((struct vnode *)); -int procfs_allocvp __P((struct mount *, struct vnode **, long, pfstype)); -int procfs_donote __P((struct proc *, struct proc *, struct pfsnode *pfsp,= struct uio *uio)); -int procfs_doregs __P((struct proc *, struct proc *, struct pfsnode *pfsp,= struct uio *uio)); -int procfs_dofpregs __P((struct proc *, struct proc *, struct pfsnode *pfs= p, struct uio *uio)); -int procfs_dodbregs __P((struct proc *, struct proc *, struct pfsnode *pfs= p, struct uio *uio)); -int procfs_domem __P((struct proc *, struct proc *, struct pfsnode *pfsp, = struct uio *uio)); -int procfs_doctl __P((struct proc *, struct proc *, struct pfsnode *pfsp, = struct uio *uio)); -int procfs_dostatus __P((struct proc *, struct proc *, struct pfsnode *pfs= p, struct uio *uio)); -int procfs_domap __P((struct proc *, struct proc *, struct pfsnode *pfsp, = struct uio *uio)); -int procfs_dotype __P((struct proc *, struct proc *, struct pfsnode *pfsp,= struct uio *uio)); -int procfs_docmdline __P((struct proc *, struct proc *, struct pfsnode *pf= sp, struct uio *uio)); -int procfs_dorlimit __P((struct proc *, struct proc *, struct pfsnode *pfs= p, struct uio *uio)); - -/* functions to check whether or not files should be displayed */ -int procfs_validfile __P((struct thread *)); -int procfs_validfpregs __P((struct thread *)); -int procfs_validregs __P((struct thread *)); -int procfs_validdbregs __P((struct thread *)); -int procfs_validmap __P((struct thread *)); -int procfs_validtype __P((struct thread *)); - -#define PROCFS_LOCKED 0x01 -#define PROCFS_WANT 0x02 =20 -extern vop_t **procfs_vnodeop_p; +int procfs_doproccmdline(PFS_FILL_ARGS); +int procfs_doprocctl(PFS_FILL_ARGS); +int procfs_doprocdbregs(PFS_FILL_ARGS); +int procfs_doprocfpregs(PFS_FILL_ARGS); +int procfs_doprocmap(PFS_FILL_ARGS); +int procfs_doprocmem(PFS_FILL_ARGS); +int procfs_doprocnote(PFS_FILL_ARGS); +int procfs_doprocregs(PFS_FILL_ARGS); +int procfs_doprocrlimit(PFS_FILL_ARGS); +int procfs_doprocstatus(PFS_FILL_ARGS); +int procfs_doproctype(PFS_FILL_ARGS); + +/* Return 1 if process has special kernel digging privileges */ +int procfs_kmemaccess(struct proc *); + +/* Attributes */ +int procfs_attr(PFS_ATTR_ARGS); + +/* Visbility */ +int procfs_notsystem(PFS_VIS_ARGS); +int procfs_candebug(PFS_VIS_ARGS); =20 -int procfs_root __P((struct mount *, struct vnode **)); -int procfs_rw __P((struct vop_read_args *)); #endif /* _KERNEL */ Index: sys/fs/procfs/procfs_ctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_ctl.c,v retrieving revision 1.33 diff -u -r1.33 procfs_ctl.c --- sys/fs/procfs/procfs_ctl.c 21 Oct 2001 23:57:11 -0000 1.33 +++ sys/fs/procfs/procfs_ctl.c 22 Oct 2001 00:03:41 -0000 @@ -41,13 +41,16 @@ #include #include #include +#include #include #include #include +#include #include #include #include =20 +#include #include =20 #include @@ -67,7 +70,12 @@ #define PROCFS_CTL_RUN 4 #define PROCFS_CTL_WAIT 5 =20 -static vfs_namemap_t ctlnames[] =3D { +struct namemap { + const char *nm_name; + int nm_val; +}; + +static struct namemap ctlnames[] =3D { /* special /proc commands */ { "attach", PROCFS_CTL_ATTACH }, { "detach", PROCFS_CTL_DETACH }, @@ -77,7 +85,7 @@ { 0 }, }; =20 -static vfs_namemap_t signames[] =3D { +static struct namemap signames[] =3D { /* regular signal names */ { "hup", SIGHUP }, { "int", SIGINT }, { "quit", SIGQUIT }, { "ill", SIGILL }, @@ -101,10 +109,7 @@ static int procfs_control __P((struct proc *curp, struct proc *p, int op)); =20 static int -procfs_control(curp, p, op) - struct proc *curp; - struct proc *p; - int op; +procfs_control(struct proc *curp, struct proc *p, int op) { int error =3D 0; =20 @@ -240,7 +245,6 @@ * Step. Let the target process execute a single instruction. */ case PROCFS_CTL_STEP: - _PHOLD(p); PROC_UNLOCK(p); error =3D proc_sstep(&p->p_thread); /* XXXKSE */ PRELE(p); @@ -301,26 +305,26 @@ return (0); } =20 +static struct namemap * +findname(struct namemap *nm, char *buf, int buflen) +{ + + for (; nm->nm_name; nm++) + if (bcmp(buf, nm->nm_name, buflen+1) =3D=3D 0) + return (nm); + + return (0); +} + int -procfs_doctl(curp, p, pfs, uio) - struct proc *curp; - struct pfsnode *pfs; - struct uio *uio; - struct proc *p; +procfs_doprocctl(PFS_FILL_ARGS) { - int xlen; int error; - char msg[PROCFS_CTLLEN+1]; - vfs_namemap_t *nm; + struct namemap *nm; =20 - if (uio->uio_rw !=3D UIO_WRITE) + if (uio =3D=3D NULL || uio->uio_rw !=3D UIO_WRITE) return (EOPNOTSUPP); =20 - xlen =3D PROCFS_CTLLEN; - error =3D vfs_getuserstr(uio, msg, &xlen); - if (error) - return (error); - /* * Map signal names into signal generation * or debug control. Unknown commands and/or signals @@ -332,15 +336,19 @@ */ error =3D EOPNOTSUPP; =20 - nm =3D vfs_findname(ctlnames, msg, xlen); + sbuf_trim(sb); + sbuf_finish(sb); + nm =3D findname(ctlnames, sbuf_data(sb), sbuf_len(sb)); if (nm) { - error =3D procfs_control(curp, p, nm->nm_val); + printf("procfs: got a %s command\n", sbuf_data(sb)); + error =3D procfs_control(td->td_proc, p, nm->nm_val); } else { - nm =3D vfs_findname(signames, msg, xlen); + nm =3D findname(signames, sbuf_data(sb), sbuf_len(sb)); if (nm) { + printf("procfs: got a sig%s\n", sbuf_data(sb)); PROC_LOCK(p); mtx_lock_spin(&sched_lock); - if (TRACE_WAIT_P(curp, p)) { + if (TRACE_WAIT_P(td->td_proc, p)) { p->p_xstat =3D nm->nm_val; #ifdef FIX_SSTEP FIX_SSTEP(&p->p_thread); /* XXXKSE */ Index: sys/fs/procfs/procfs_dbregs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_dbregs.c,v retrieving revision 1.14 diff -u -r1.14 procfs_dbregs.c --- sys/fs/procfs/procfs_dbregs.c 21 Oct 2001 23:57:11 -0000 1.14 +++ sys/fs/procfs/procfs_dbregs.c 22 Oct 2001 00:03:41 -0000 @@ -46,30 +46,29 @@ #include #include #include +#include #include #include #include +#include #include =20 #include =20 +#include #include =20 #include =20 int -procfs_dodbregs(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocdbregs(PFS_FILL_ARGS) { int error; struct dbreg r; char *kv; int kl; =20 - if (p_candebug(curp, p)) + if (p_candebug(td->td_proc, p) !=3D 0) return (EPERM); kl =3D sizeof(r); kv =3D (char *) &r; @@ -79,8 +78,6 @@ if (kl > uio->uio_resid) kl =3D uio->uio_resid; =20 - PHOLD(p); - if (kl < 0) error =3D EINVAL; else @@ -93,15 +90,7 @@ else error =3D proc_write_dbregs(&p->p_thread, &r); /* XXXKSE */ } - PRELE(p); =20 uio->uio_offset =3D 0; return (error); -} - -int -procfs_validdbregs(struct thread *td) -{ - - return ((td->td_proc->p_flag & P_SYSTEM) =3D=3D 0); } Index: sys/fs/procfs/procfs_fpregs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_fpregs.c,v retrieving revision 1.21 diff -u -r1.21 procfs_fpregs.c --- sys/fs/procfs/procfs_fpregs.c 21 Oct 2001 23:57:11 -0000 1.21 +++ sys/fs/procfs/procfs_fpregs.c 22 Oct 2001 00:03:41 -0000 @@ -43,30 +43,29 @@ #include #include #include +#include #include #include #include +#include #include =20 #include =20 +#include #include =20 #include =20 int -procfs_dofpregs(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocfpregs(PFS_FILL_ARGS) { int error; struct fpreg r; char *kv; int kl; =20 - if (p_candebug(curp, p)) + if (p_candebug(td->td_proc, p)) return EPERM; kl =3D sizeof(r); kv =3D (char *) &r; @@ -94,11 +93,4 @@ =20 uio->uio_offset =3D 0; return (error); -} - -int -procfs_validfpregs(struct thread *td) -{ - - return (( td->td_proc->p_flag & P_SYSTEM) =3D=3D 0); } Index: sys/fs/procfs/procfs_map.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_map.c,v retrieving revision 1.30 diff -u -r1.30 procfs_map.c --- sys/fs/procfs/procfs_map.c 12 Sep 2001 08:37:20 -0000 1.30 +++ sys/fs/procfs/procfs_map.c 5 Oct 2001 11:08:38 -0000 @@ -42,10 +42,13 @@ #include #include #include +#include #include #include +#include #include =20 +#include #include =20 #include @@ -68,11 +71,7 @@ * can try a bigger buffer. */ int -procfs_domap(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocmap(PFS_FILL_ARGS) { int len; int error; @@ -90,7 +89,7 @@ return (0); =20=09 error =3D 0; - if (map !=3D &curproc->p_vmspace->vm_map) + if (map !=3D &curthread->td_proc->p_vmspace->vm_map) vm_map_lock_read(map); for (entry =3D map->header.next; ((uio->uio_resid > 0) && (entry !=3D &map->header)); @@ -118,23 +117,22 @@ addr +=3D PAGE_SIZE; } =20 - for( lobj =3D tobj =3D obj; tobj; tobj =3D tobj->backing_object) + for (lobj =3D tobj =3D obj; tobj; tobj =3D tobj->backing_object) lobj =3D tobj; =20 if (lobj) { switch(lobj->type) { - -default: -case OBJT_DEFAULT: + default: + case OBJT_DEFAULT: type =3D "default"; break; -case OBJT_VNODE: + case OBJT_VNODE: type =3D "vnode"; break; -case OBJT_SWAP: + case OBJT_SWAP: type =3D "swap"; break; -case OBJT_DEVICE: + case OBJT_DEVICE: type =3D "device"; break; } @@ -148,13 +146,12 @@ ref_count =3D 0; shadow_count =3D 0; } -=09=09=09 =20 /* * format: * start, end, resident, private resident, cow, access, type. */ - snprintf(mebuffer, sizeof(mebuffer), + snprintf(mebuffer, sizeof mebuffer, "0x%lx 0x%lx %d %d %p %s%s%s %d %d 0x%x %s %s %s\n", (u_long)entry->start, (u_long)entry->end, resident, privateresident, obj, @@ -175,14 +172,8 @@ if (error) break; } - if (map !=3D &curproc->p_vmspace->vm_map) + if (map !=3D &curthread->td_proc->p_vmspace->vm_map) vm_map_unlock_read(map); =20=09 - return error; -} - -int -procfs_validmap(struct thread *td) -{ - return ((td->td_proc->p_flag & P_SYSTEM) =3D=3D 0); + return (error); } Index: sys/fs/procfs/procfs_mem.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_mem.c,v retrieving revision 1.54 diff -u -r1.54 procfs_mem.c --- sys/fs/procfs/procfs_mem.c 7 Oct 2001 20:08:37 -0000 1.54 +++ sys/fs/procfs/procfs_mem.c 8 Oct 2001 00:00:00 -0000 @@ -43,12 +43,15 @@ #include #include #include +#include #include #include #include +#include #include #include =20 +#include #include =20 /* @@ -58,20 +61,17 @@ * from the kernel address space. */ int -procfs_domem(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocmem(PFS_FILL_ARGS) { int error; =20 if (uio->uio_resid =3D=3D 0) return (0); =20 - error =3D p_candebug(curp, p); + error =3D p_candebug(td->td_proc, p); if (error) return (error); + error =3D proc_rwmem(p, uio); =20 - return (proc_rwmem(p, uio)); + return (error); } Index: sys/fs/procfs/procfs_note.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_note.c,v retrieving revision 1.7 diff -u -r1.7 procfs_note.c --- sys/fs/procfs/procfs_note.c 23 May 2001 09:42:11 -0000 1.7 +++ sys/fs/procfs/procfs_note.c 4 Oct 2001 11:21:39 -0000 @@ -40,28 +40,18 @@ */ =20 #include +#include +#include #include + +#include #include =20 int -procfs_donote(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocnote(PFS_FILL_ARGS) { - int xlen; - int error; - char note[PROCFS_NOTELEN+1]; - - if (uio->uio_rw !=3D UIO_WRITE) - return (EINVAL); - - xlen =3D PROCFS_NOTELEN; - error =3D vfs_getuserstr(uio, note, &xlen); - if (error) - return (error); - + sbuf_trim(sb); + sbuf_finish(sb); /* send to process's notify function */ return (EOPNOTSUPP); } Index: sys/fs/procfs/procfs_regs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_regs.c,v retrieving revision 1.20 diff -u -r1.20 procfs_regs.c --- sys/fs/procfs/procfs_regs.c 21 Oct 2001 23:57:11 -0000 1.20 +++ sys/fs/procfs/procfs_regs.c 22 Oct 2001 00:03:41 -0000 @@ -43,9 +43,11 @@ #include #include #include +#include #include #include #include +#include #include =20 #include @@ -53,21 +55,18 @@ #include #include =20 +#include #include =20 int -procfs_doregs(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocregs(PFS_FILL_ARGS) { int error; struct reg r; char *kv; int kl; =20 - if (p_candebug(curp, p)) + if (p_candebug(td->td_proc, p)) return EPERM; kl =3D sizeof(r); kv =3D (char *) &r; @@ -95,11 +94,4 @@ =20 uio->uio_offset =3D 0; return (error); -} - -int -procfs_validregs(struct thread *td) -{ - - return ((td->td_proc->p_flag & P_SYSTEM) =3D=3D 0); } Index: sys/fs/procfs/procfs_rlimit.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_rlimit.c,v retrieving revision 1.6 diff -u -r1.6 procfs_rlimit.c --- sys/fs/procfs/procfs_rlimit.c 23 May 2001 09:42:11 -0000 1.6 +++ sys/fs/procfs/procfs_rlimit.c 28 Sep 2001 12:37:19 -0000 @@ -47,32 +47,22 @@ =20 #include #include +#include #include #include #include #include +#include #include + +#include #include =20 =20 int -procfs_dorlimit(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocrlimit(PFS_FILL_ARGS) { - char *ps; int i; - int xlen; - int error; - char psbuf[512]; /* XXX - conservative */ - - if (uio->uio_rw !=3D UIO_READ) - return (EOPNOTSUPP); - - - ps =3D psbuf; =20 for (i =3D 0; i < RLIM_NLIMITS; i++) { =20 @@ -80,7 +70,7 @@ * Add the rlimit ident */ =20 - ps +=3D sprintf(ps, "%s ", rlimit_ident[i]); + sbuf_printf(sb, "%s ", rlimit_ident[i]); =20 /*=20 * Replace RLIM_INFINITY with -1 in the string @@ -91,9 +81,9 @@ */ =20 if (p->p_rlimit[i].rlim_cur =3D=3D RLIM_INFINITY) { - ps +=3D sprintf(ps, "-1 "); + sbuf_printf(sb, "-1 "); } else { - ps +=3D sprintf(ps, "%llu ", + sbuf_printf(sb, "%llu ", (unsigned long long)p->p_rlimit[i].rlim_cur); } =20 @@ -102,27 +92,13 @@ */ =20 if (p->p_rlimit[i].rlim_max =3D=3D RLIM_INFINITY) { - ps +=3D sprintf(ps, "-1\n"); + sbuf_printf(sb, "-1\n"); } else { - ps +=3D sprintf(ps, "%llu\n", + sbuf_printf(sb, "%llu\n", (unsigned long long)p->p_rlimit[i].rlim_max); } } =20 - /* - * This logic is rather tasty - but its from procfs_status.c, so - * I guess I'll use it here. - */ - - xlen =3D ps - psbuf; - xlen -=3D uio->uio_offset; - ps =3D psbuf + uio->uio_offset; - xlen =3D imin(xlen, uio->uio_resid); - if (xlen <=3D 0) - error =3D 0; - else - error =3D uiomove(ps, xlen, uio); - - return (error); + return (0); } =20 Index: sys/fs/procfs/procfs_status.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_status.c,v retrieving revision 1.35 diff -u -r1.35 procfs_status.c --- sys/fs/procfs/procfs_status.c 28 Oct 2001 22:53:45 -0000 1.35 +++ sys/fs/procfs/procfs_status.c 29 Oct 2001 19:02:08 -0000 @@ -46,9 +46,11 @@ #include #include #include +#include #include #include #include +#include #include #include =20 @@ -56,29 +58,19 @@ #include #include =20 +#include #include =20 -#define DOCHECK() do { if (ps >=3D psbuf+sizeof(psbuf)) goto bailout; } wh= ile (0) int -procfs_dostatus(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doprocstatus(PFS_FILL_ARGS) { struct session *sess; struct tty *tp; struct ucred *cr; - char *ps, *pc; + char *pc; char *sep; int pid, ppid, pgid, sid; int i; - int xlen; - int error; - char psbuf[256]; /* XXX - conservative */ - - if (uio->uio_rw !=3D UIO_READ) - return (EOPNOTSUPP); =20 pid =3D p->p_pid; PROC_LOCK(p); @@ -91,45 +83,31 @@ /* comm pid ppid pgid sid maj,min ctty,sldr start ut st wmsg=20 euid ruid rgid,egid,groups[1 .. NGROUPS] */ - KASSERT(sizeof(psbuf) > MAXCOMLEN, - ("Too short buffer for new MAXCOMLEN")); =20 - ps =3D psbuf; pc =3D p->p_comm; - xlen =3D strlen(p->p_comm); do { if (*pc < 33 || *pc > 126 || *pc =3D=3D '\\') - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, "\\%03o", - *pc); + sbuf_printf(sb, "\\%03o", *pc); else - *ps++ =3D *pc; - DOCHECK(); - } while (++pc < p->p_comm + xlen); - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, - " %d %d %d %d ", pid, ppid, pgid, sid); - DOCHECK(); + sbuf_putc(sb, *pc); + } while (*++pc); + sbuf_printf(sb, " %d %d %d %d ", pid, ppid, pgid, sid); if ((p->p_flag&P_CONTROLT) && (tp =3D sess->s_ttyp)) - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, - "%d,%d ", major(tp->t_dev), minor(tp->t_dev)); + sbuf_printf(sb, "%d,%d ", major(tp->t_dev), minor(tp->t_dev)); else - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, - "%d,%d ", -1, -1); - DOCHECK(); + sbuf_printf(sb, "%d,%d ", -1, -1); =20 sep =3D ""; if (sess->s_ttyvp) { - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, "%sctty", sep); + sbuf_printf(sb, "%sctty", sep); sep =3D ","; - DOCHECK(); } if (SESS_LEADER(p)) { - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, "%ssldr", sep); + sbuf_printf(sb, "%ssldr", sep); sep =3D ","; - DOCHECK(); } if (*sep !=3D ',') { - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, "noflags"); - DOCHECK(); + sbuf_printf(sb, "noflags"); } =20 mtx_lock_spin(&sched_lock); @@ -138,89 +116,53 @@ =20 calcru(p, &ut, &st, (struct timeval *) NULL); mtx_unlock_spin(&sched_lock); - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, - " %lld,%ld %lld,%ld %lld,%ld", - (quad_t)p->p_stats->p_start.tv_sec, + sbuf_printf(sb, " %ld,%ld %ld,%ld %ld,%ld", + p->p_stats->p_start.tv_sec, p->p_stats->p_start.tv_usec, - (quad_t)ut.tv_sec, ut.tv_usec, - (quad_t)st.tv_sec, st.tv_usec); + ut.tv_sec, ut.tv_usec, + st.tv_sec, st.tv_usec); } else { mtx_unlock_spin(&sched_lock); - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, - " -1,-1 -1,-1 -1,-1"); + sbuf_printf(sb, " -1,-1 -1,-1 -1,-1"); } - DOCHECK(); =20 if (p->p_flag & P_KSES) { - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, " %s", - "-kse- "); + sbuf_printf(sb, " %s", "-kse- "); } else { - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, " %s", + sbuf_printf(sb, " %s", (p->p_thread.td_wchan && p->p_thread.td_wmesg) ? p->p_thread.td_wmesg : "nochan"); } - DOCHECK(); =20 cr =3D p->p_ucred; =20 - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, " %lu %lu %lu",=20 + sbuf_printf(sb, " %lu %lu %lu", (u_long)cr->cr_uid, (u_long)cr->cr_ruid, (u_long)cr->cr_rgid); - DOCHECK(); =20 /* egid (cr->cr_svgid) is equal to cr_ngroups[0]=20 see also getegid(2) in /sys/kern/kern_prot.c */ =20 for (i =3D 0; i < cr->cr_ngroups; i++) { - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, - ",%lu", (u_long)cr->cr_groups[i]); - DOCHECK(); + sbuf_printf(sb, ",%lu", (u_long)cr->cr_groups[i]); } =20 if (jailed(p->p_ucred)) - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, - " %s", p->p_ucred->cr_prison->pr_host); - else - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, " -"); - DOCHECK(); - ps +=3D snprintf(ps, psbuf + sizeof(psbuf) - ps, "\n"); - DOCHECK(); - - xlen =3D ps - psbuf; - xlen -=3D uio->uio_offset; - ps =3D psbuf + uio->uio_offset; - xlen =3D imin(xlen, uio->uio_resid); - if (xlen <=3D 0) - error =3D 0; + sbuf_printf(sb, " %s", p->p_ucred->cr_prison->pr_host); else - error =3D uiomove(ps, xlen, uio); - - return (error); + sbuf_printf(sb, " -"); + sbuf_printf(sb, "\n"); =20 -bailout: - return (ENOMEM); + return (0); } =20 int -procfs_docmdline(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doproccmdline(PFS_FILL_ARGS) { - char *ps; - int xlen; - int error; - char *buf, *bp; - int buflen; struct ps_strings pstr; - int i; - size_t bytes_left, done; + int error, i; =20 - if (uio->uio_rw !=3D UIO_READ) - return (EOPNOTSUPP); -=09 /* * If we are using the ps/cmdline caching, use that. Otherwise * revert back to the old way which only implements full cmdline @@ -231,47 +173,19 @@ * Linux behaviour is to return zero-length in this case. */ =20 - if (p->p_args && (ps_argsopen || !p_cansee(curp, p))) { - bp =3D p->p_args->ar_args; - buflen =3D p->p_args->ar_length; - buf =3D 0; - } else if (p !=3D curp) { - bp =3D p->p_comm; - buflen =3D MAXCOMLEN; - buf =3D 0; + if (p->p_args && (ps_argsopen || !p_cansee(td->td_proc, p))) { + sbuf_bcpy(sb, p->p_args->ar_args, p->p_args->ar_length); + } else if (p !=3D td->td_proc) { + sbuf_printf(sb, "%.*s", MAXCOMLEN, p->p_comm); } else { - buflen =3D 256; - MALLOC(buf, char *, buflen + 1, M_TEMP, M_WAITOK); - bp =3D buf; - ps =3D buf; error =3D copyin((void*)PS_STRINGS, &pstr, sizeof(pstr)); - if (error) { - FREE(buf, M_TEMP); + if (error) return (error); + for (i =3D 0; i < pstr.ps_nargvstr; i++) { + sbuf_copyin(sb, pstr.ps_argvstr[i], 0); + sbuf_printf(sb, "%c", '\0'); } - bytes_left =3D buflen; - for (i =3D 0; bytes_left && (i < pstr.ps_nargvstr); i++) { - error =3D copyinstr(pstr.ps_argvstr[i], ps, - bytes_left, &done); - /* If too long or malformed, just truncate */ - if (error) { - error =3D 0; - break; - } - ps +=3D done; - bytes_left -=3D done; - } - buflen =3D ps - buf; } =20 - buflen -=3D uio->uio_offset; - ps =3D bp + uio->uio_offset; - xlen =3D min(buflen, uio->uio_resid); - if (xlen <=3D 0) - error =3D 0; - else - error =3D uiomove(ps, xlen, uio); - if (buf) - FREE(buf, M_TEMP); - return (error); + return (0); } Index: sys/fs/procfs/procfs_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: sys/fs/procfs/procfs_subr.c diff -N sys/fs/procfs/procfs_subr.c --- sys/fs/procfs/procfs_subr.c 18 Sep 2001 19:53:10 -0000 1.37 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,413 +0,0 @@ -/* - * Copyright (c) 1993 Jan-Simon Pendry - * Copyright (c) 1993 - * The Regents of the University of California. All rights reserved. - * - * This code is derived from software contributed to Berkeley by - * Jan-Simon Pendry. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes software developed by the University of - * California, Berkeley and its contributors. - * 4. Neither the name of the University nor the names of its contributors - * may be used to endorse or promote products derived from this software - * without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * @(#)procfs_subr.c 8.6 (Berkeley) 5/14/95 - * - * $FreeBSD: src/sys/fs/procfs/procfs_subr.c,v 1.37 2001/09/18 19:53:10 rw= atson Exp $ - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -static struct pfsnode *pfshead; -static int pfsvplock; - -/* - * allocate a pfsnode/vnode pair. the vnode is - * referenced, but not locked. - * - * the pid, pfs_type, and mount point uniquely - * identify a pfsnode. the mount point is needed - * because someone might mount this filesystem - * twice. - * - * all pfsnodes are maintained on a singly-linked - * list. new nodes are only allocated when they cannot - * be found on this list. entries on the list are - * removed when the vfs reclaim entry is called. - * - * a single lock is kept for the entire list. this is - * needed because the getnewvnode() function can block - * waiting for a vnode to become free, in which case there - * may be more than one process trying to get the same - * vnode. this lock is only taken if we are going to - * call getnewvnode, since the kernel itself is single-threaded. - * - * if an entry is found on the list, then call vget() to - * take a reference. this is done because there may be - * zero references to it and so it needs to removed from - * the vnode free list. - */ -int -procfs_allocvp(mp, vpp, pid, pfs_type) - struct mount *mp; - struct vnode **vpp; - long pid; - pfstype pfs_type; -{ - struct thread *td =3D curthread; /* XXX */ - struct pfsnode *pfs; - struct vnode *vp; - struct pfsnode **pp; - int error; - -loop: - for (pfs =3D pfshead; pfs !=3D 0; pfs =3D pfs->pfs_next) { - vp =3D PFSTOV(pfs); - if (pfs->pfs_pid =3D=3D pid && - pfs->pfs_type =3D=3D pfs_type && - vp->v_mount =3D=3D mp) { - if (vget(vp, 0, td)) - goto loop; - *vpp =3D vp; - return (0); - } - } - - /* - * otherwise lock the vp list while we call getnewvnode - * since that can block. - */ - if (pfsvplock & PROCFS_LOCKED) { - pfsvplock |=3D PROCFS_WANT; - (void) tsleep((caddr_t) &pfsvplock, PINOD, "pfsavp", 0); - goto loop; - } - pfsvplock |=3D PROCFS_LOCKED; - - /* - * Do the MALLOC before the getnewvnode since doing so afterward - * might cause a bogus v_data pointer to get dereferenced - * elsewhere if MALLOC should block. - */ - MALLOC(pfs, struct pfsnode *, sizeof(struct pfsnode), M_TEMP, M_WAITOK); - - if ((error =3D getnewvnode(VT_PROCFS, mp, procfs_vnodeop_p, vpp)) !=3D 0)= { - FREE(pfs, M_TEMP); - goto out; - } - vp =3D *vpp; - - vp->v_data =3D pfs; - - pfs->pfs_next =3D 0; - pfs->pfs_pid =3D (pid_t) pid; - pfs->pfs_type =3D pfs_type; - pfs->pfs_vnode =3D vp; - pfs->pfs_flags =3D 0; - pfs->pfs_lockowner =3D 0; - pfs->pfs_fileno =3D PROCFS_FILENO(pid, pfs_type); - - switch (pfs_type) { - case Proot: /* /proc =3D dr-xr-xr-x */ - pfs->pfs_mode =3D (VREAD|VEXEC) | - (VREAD|VEXEC) >> 3 | - (VREAD|VEXEC) >> 6; - vp->v_type =3D VDIR; - vp->v_flag =3D VROOT; - break; - - case Pcurproc: /* /proc/curproc =3D lr--r--r-- */ - pfs->pfs_mode =3D (VREAD) | - (VREAD >> 3) | - (VREAD >> 6); - vp->v_type =3D VLNK; - break; - - case Pproc: - pfs->pfs_mode =3D (VREAD|VEXEC) | - (VREAD|VEXEC) >> 3 | - (VREAD|VEXEC) >> 6; - vp->v_type =3D VDIR; - break; - - case Pfile: - pfs->pfs_mode =3D (VREAD|VEXEC) | - (VREAD|VEXEC) >> 3 | - (VREAD|VEXEC) >> 6; - vp->v_type =3D VLNK; - break; - - case Pmem: - pfs->pfs_mode =3D (VREAD|VWRITE); - vp->v_type =3D VREG; - break; - - case Pregs: - case Pfpregs: - case Pdbregs: - pfs->pfs_mode =3D (VREAD|VWRITE); - vp->v_type =3D VREG; - break; - - case Pctl: - case Pnote: - case Pnotepg: - pfs->pfs_mode =3D (VWRITE); - vp->v_type =3D VREG; - break; - - case Ptype: - case Pmap: - case Pstatus: - case Pcmdline: - case Prlimit: - pfs->pfs_mode =3D (VREAD) | - (VREAD >> 3) | - (VREAD >> 6); - vp->v_type =3D VREG; - break; - - default: - panic("procfs_allocvp"); - } - - /* add to procfs vnode list */ - for (pp =3D &pfshead; *pp; pp =3D &(*pp)->pfs_next) - continue; - *pp =3D pfs; - -out: - pfsvplock &=3D ~PROCFS_LOCKED; - - if (pfsvplock & PROCFS_WANT) { - pfsvplock &=3D ~PROCFS_WANT; - wakeup((caddr_t) &pfsvplock); - } - - return (error); -} - -int -procfs_freevp(vp) - struct vnode *vp; -{ - struct pfsnode **pfspp; - struct pfsnode *pfs =3D VTOPFS(vp); - - for (pfspp =3D &pfshead; *pfspp !=3D 0; pfspp =3D &(*pfspp)->pfs_next) { - if (*pfspp =3D=3D pfs) { - *pfspp =3D pfs->pfs_next; - break; - } - } - - FREE(vp->v_data, M_TEMP); - vp->v_data =3D 0; - return (0); -} - -int -procfs_rw(ap) - struct vop_read_args *ap; -{ - struct vnode *vp =3D ap->a_vp; - struct uio *uio =3D ap->a_uio; - struct proc *curp =3D uio->uio_td->td_proc; - struct pfsnode *pfs =3D VTOPFS(vp); - struct proc *p; - int rtval; - - p =3D PFIND(pfs->pfs_pid); - if (p =3D=3D NULL) - return (EINVAL); - PROC_UNLOCK(p); - - mp_fixme("pfs_lockowner needs a lock"); - while (pfs->pfs_lockowner) { - tsleep(&pfs->pfs_lockowner, PRIBIO, "pfslck", 0); - } - pfs->pfs_lockowner =3D curproc->p_pid; - - switch (pfs->pfs_type) { - case Pnote: - case Pnotepg: - rtval =3D procfs_donote(curp, p, pfs, uio); - break; - - case Pregs: - rtval =3D procfs_doregs(curp, p, pfs, uio); - break; - - case Pfpregs: - rtval =3D procfs_dofpregs(curp, p, pfs, uio); - break; - - case Pdbregs: - rtval =3D procfs_dodbregs(curp, p, pfs, uio); - break; - - case Pctl: - rtval =3D procfs_doctl(curp, p, pfs, uio); - break; - - case Pstatus: - rtval =3D procfs_dostatus(curp, p, pfs, uio); - break; - - case Pmap: - rtval =3D procfs_domap(curp, p, pfs, uio); - break; - - case Pmem: - rtval =3D procfs_domem(curp, p, pfs, uio); - break; - - case Ptype: - rtval =3D procfs_dotype(curp, p, pfs, uio); - break; - - case Pcmdline: - rtval =3D procfs_docmdline(curp, p, pfs, uio); - break; - - case Prlimit: - rtval =3D procfs_dorlimit(curp, p, pfs, uio); - break; - - default: - rtval =3D EOPNOTSUPP; - break; - } - pfs->pfs_lockowner =3D 0; - wakeup(&pfs->pfs_lockowner); - return rtval; -} - -/* - * Get a string from userland into (buf). Strip a trailing - * nl character (to allow easy access from the shell). - * The buffer should be *buflenp + 1 chars long. vfs_getuserstr - * will automatically add a nul char at the end. - * - * Returns 0 on success or the following errors - * - * EINVAL: file offset is non-zero. - * EMSGSIZE: message is longer than kernel buffer - * EFAULT: user i/o buffer is not addressable - */ -int -vfs_getuserstr(uio, buf, buflenp) - struct uio *uio; - char *buf; - int *buflenp; -{ - int xlen; - int error; - - if (uio->uio_offset !=3D 0) - return (EINVAL); - - xlen =3D *buflenp; - - /* must be able to read the whole string in one go */ - if (xlen < uio->uio_resid) - return (EMSGSIZE); - xlen =3D uio->uio_resid; - - if ((error =3D uiomove(buf, xlen, uio)) !=3D 0) - return (error); - - /* allow multiple writes without seeks */ - uio->uio_offset =3D 0; - - /* cleanup string and remove trailing newline */ - buf[xlen] =3D '\0'; - xlen =3D strlen(buf); - if (xlen > 0 && buf[xlen-1] =3D=3D '\n') - buf[--xlen] =3D '\0'; - *buflenp =3D xlen; - - return (0); -} - -vfs_namemap_t * -vfs_findname(nm, buf, buflen) - vfs_namemap_t *nm; - char *buf; - int buflen; -{ - - for (; nm->nm_name; nm++) - if (bcmp(buf, nm->nm_name, buflen+1) =3D=3D 0) - return (nm); - - return (0); -} - -void -procfs_exit(struct proc *p) -{ - struct pfsnode *pfs; - pid_t pid =3D p->p_pid; - - /* - * The reason for this loop is not obvious -- basicly, - * procfs_freevp(), which is called via vgone() (eventually), - * removes the specified procfs node from the pfshead list. - * It does this by *pfsp =3D pfs->pfs_next, meaning that it - * overwrites the node. So when we do pfs =3D pfs->next, we - * end up skipping the node that replaces the one that was - * vgone'd. Since it may have been the last one on the list, - * it may also have been set to null -- but *our* pfs pointer, - * here, doesn't see this. So the loop starts from the beginning - * again. - * - * This is not a for() loop because the final event - * would be "pfs =3D pfs->pfs_next"; in the case where - * pfs is set to pfshead again, that would mean that - * pfshead is skipped over. - * - */ - pfs =3D pfshead; - while (pfs) { - if (pfs->pfs_pid =3D=3D pid) { - vgone(PFSTOV(pfs)); - pfs =3D pfshead; - } else - pfs =3D pfs->pfs_next; - } -} Index: sys/fs/procfs/procfs_type.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/fs/procfs/procfs_type.c,v retrieving revision 1.8 diff -u -r1.8 procfs_type.c --- sys/fs/procfs/procfs_type.c 12 Sep 2001 08:37:20 -0000 1.8 +++ sys/fs/procfs/procfs_type.c 1 Oct 2001 02:27:34 -0000 @@ -39,46 +39,25 @@ =20 #include #include +#include #include +#include #include #include + +#include #include =20 int -procfs_dotype(curp, p, pfs, uio) - struct proc *curp; - struct proc *p; - struct pfsnode *pfs; - struct uio *uio; +procfs_doproctype(PFS_FILL_ARGS) { - int len; - int error; - /* - * buffer for emulation type - */ - char mebuffer[256]; - char *none =3D "Not Available"; - - if (uio->uio_rw !=3D UIO_READ) - return (EOPNOTSUPP); - - if (uio->uio_offset !=3D 0) - return (0); + static const char *none =3D "Not Available"; =20 if (p && p->p_sysent && p->p_sysent->sv_name) { - len =3D strlen(p->p_sysent->sv_name); - bcopy(p->p_sysent->sv_name, mebuffer, len); + sbuf_printf(sb, p->p_sysent->sv_name); } else { - len =3D strlen(none); - bcopy(none, mebuffer, len); + sbuf_printf(sb, none); } - mebuffer[len++] =3D '\n'; - error =3D uiomove(mebuffer, len, uio); - return error; -} - -int -procfs_validtype(struct thread *td) -{ - return ((td->td_proc->p_flag & P_SYSTEM) =3D=3D 0); + sbuf_putc(sb, '\n'); + return (0); } Index: sys/fs/procfs/procfs_vfsops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: sys/fs/procfs/procfs_vfsops.c diff -N sys/fs/procfs/procfs_vfsops.c --- sys/fs/procfs/procfs_vfsops.c 12 Sep 2001 08:37:20 -0000 1.38 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,177 +0,0 @@ -/* - * Copyright (c) 1993 Jan-Simon Pendry - * Copyright (c) 1993 - * The Regents of the University of California. All rights reserved. - * - * This code is derived from software contributed to Berkeley by - * Jan-Simon Pendry. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes software developed by the University of - * California, Berkeley and its contributors. - * 4. Neither the name of the University nor the names of its contributors - * may be used to endorse or promote products derived from this software - * without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * @(#)procfs_vfsops.c 8.7 (Berkeley) 5/10/95 - * - * $FreeBSD: src/sys/fs/procfs/procfs_vfsops.c,v 1.38 2001/09/12 08:37:20 = julian Exp $ - */ - -/* - * procfs VFS interface - */ - -#include -#include -#include -#include -#include -#include -#include - -static int procfs_mount __P((struct mount *mp, char *path, caddr_t data, - struct nameidata *ndp, struct thread *td)); -static int procfs_statfs __P((struct mount *mp, struct statfs *sbp, - struct thread *td)); -static int procfs_unmount __P((struct mount *mp, int mntflags, - struct thread *td)); - -/* - * VFS Operations. - * - * mount system call - */ -/* ARGSUSED */ -static int -procfs_mount(mp, path, data, ndp, td) - struct mount *mp; - char *path; - caddr_t data; - struct nameidata *ndp; - struct thread *td; -{ - size_t size; - int error; - - if (mp->mnt_flag & MNT_UPDATE) - return (EOPNOTSUPP); - - if (mp->mnt_vfc->vfc_refcount =3D=3D 1 && (error =3D at_exit(procfs_exit)= )) { - printf("procfs: cannot register procfs_exit with at_exit\n"); - return(error); - } - - mp->mnt_flag |=3D MNT_LOCAL; - mp->mnt_data =3D 0; - vfs_getnewfsid(mp); - - size =3D sizeof("procfs") - 1; - bcopy("procfs", mp->mnt_stat.f_mntfromname, size); - bzero(mp->mnt_stat.f_mntfromname + size, MNAMELEN - size); - (void)procfs_statfs(mp, &mp->mnt_stat, td); - - return (0); -} - -/* - * unmount system call - */ -static int -procfs_unmount(mp, mntflags, td) - struct mount *mp; - int mntflags; - struct thread *td; -{ - int error; - int flags =3D 0; - - if (mntflags & MNT_FORCE) - flags |=3D FORCECLOSE; - - error =3D vflush(mp, 0, flags); - if (error) - return (error); - - if (mp->mnt_vfc->vfc_refcount =3D=3D 1) - rm_at_exit(procfs_exit); - - return (0); -} - -int -procfs_root(mp, vpp) - struct mount *mp; - struct vnode **vpp; -{ - - return (procfs_allocvp(mp, vpp, 0, Proot)); -} - -/* - * Get file system statistics. - */ -static int -procfs_statfs(mp, sbp, td) - struct mount *mp; - struct statfs *sbp; - struct thread *td; -{ - sbp->f_bsize =3D PAGE_SIZE; - sbp->f_iosize =3D PAGE_SIZE; - sbp->f_blocks =3D 1; /* avoid divide by zero in some df's */ - sbp->f_bfree =3D 0; - sbp->f_bavail =3D 0; - sbp->f_files =3D maxproc; /* approx */ - sbp->f_ffree =3D maxproc - nprocs; /* approx */ - - if (sbp !=3D &mp->mnt_stat) { - sbp->f_type =3D mp->mnt_vfc->vfc_typenum; - bcopy(&mp->mnt_stat.f_fsid, &sbp->f_fsid, sizeof(sbp->f_fsid)); - bcopy(mp->mnt_stat.f_mntonname, sbp->f_mntonname, MNAMELEN); - bcopy(mp->mnt_stat.f_mntfromname, sbp->f_mntfromname, MNAMELEN); - } - - return (0); -} - -static struct vfsops procfs_vfsops =3D { - procfs_mount, - vfs_stdstart, - procfs_unmount, - procfs_root, - vfs_stdquotactl, - procfs_statfs, - vfs_stdsync, - vfs_stdvget, - vfs_stdfhtovp, - vfs_stdcheckexp, - vfs_stdvptofh, - vfs_stdinit, - vfs_stduninit, - vfs_stdextattrctl, -}; - -VFS_SET(procfs_vfsops, procfs, VFCF_SYNTHETIC); -MODULE_VERSION(procfs, 1); Index: sys/fs/procfs/procfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: sys/fs/procfs/procfs_vnops.c diff -N sys/fs/procfs/procfs_vnops.c --- sys/fs/procfs/procfs_vnops.c 22 Oct 2001 16:13:38 -0000 1.104 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,1023 +0,0 @@ -/* - * Copyright (c) 1993, 1995 Jan-Simon Pendry - * Copyright (c) 1993, 1995 - * The Regents of the University of California. All rights reserved. - * - * This code is derived from software contributed to Berkeley by - * Jan-Simon Pendry. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes software developed by the University of - * California, Berkeley and its contributors. - * 4. Neither the name of the University nor the names of its contributors - * may be used to endorse or promote products derived from this software - * without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * @(#)procfs_vnops.c 8.18 (Berkeley) 5/21/95 - * - * $FreeBSD: src/sys/fs/procfs/procfs_vnops.c,v 1.104 2001/10/22 16:13:38 = des Exp $ - */ - -/* - * procfs vnode interface - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -#include - -#include - -static int procfs_access __P((struct vop_access_args *)); -static int procfs_badop __P((void)); -static int procfs_close __P((struct vop_close_args *)); -static int procfs_getattr __P((struct vop_getattr_args *)); -static int procfs_ioctl __P((struct vop_ioctl_args *)); -static int procfs_lookup __P((struct vop_lookup_args *)); -static int procfs_open __P((struct vop_open_args *)); -static int procfs_print __P((struct vop_print_args *)); -static int procfs_readdir __P((struct vop_readdir_args *)); -static int procfs_readlink __P((struct vop_readlink_args *)); -static int procfs_reclaim __P((struct vop_reclaim_args *)); -static int procfs_setattr __P((struct vop_setattr_args *)); - -/* - * This is a list of the valid names in the - * process-specific sub-directories. It is - * used in procfs_lookup and procfs_readdir - */ -static struct proc_target { - u_char pt_type; - u_char pt_namlen; - char *pt_name; - pfstype pt_pfstype; - int (*pt_valid) __P((struct thread *p)); -} proc_targets[] =3D { -#define N(s) sizeof(s)-1, s - /* name type validp */ - { DT_DIR, N("."), Pproc, NULL }, - { DT_DIR, N(".."), Proot, NULL }, - { DT_REG, N("mem"), Pmem, NULL }, - { DT_REG, N("regs"), Pregs, procfs_validregs }, - { DT_REG, N("fpregs"), Pfpregs, procfs_validfpregs }, - { DT_REG, N("dbregs"), Pdbregs, procfs_validdbregs }, - { DT_REG, N("ctl"), Pctl, NULL }, - { DT_REG, N("status"), Pstatus, NULL }, - { DT_REG, N("note"), Pnote, NULL }, - { DT_REG, N("notepg"), Pnotepg, NULL }, - { DT_REG, N("map"), Pmap, procfs_validmap }, - { DT_REG, N("etype"), Ptype, procfs_validtype }, - { DT_REG, N("cmdline"), Pcmdline, NULL }, - { DT_REG, N("rlimit"), Prlimit, NULL }, - { DT_LNK, N("file"), Pfile, NULL }, -#undef N -}; -static const int nproc_targets =3D sizeof(proc_targets) / sizeof(proc_targ= ets[0]); - -static pid_t atopid __P((const char *, u_int)); - -/* - * set things up for doing i/o on - * the pfsnode (vp). (vp) is locked - * on entry, and should be left locked - * on exit. - * - * for procfs we don't need to do anything - * in particular for i/o. all that is done - * is to support exclusive open on process - * memory images. - */ -static int -procfs_open(ap) - struct vop_open_args /* { - struct vnode *a_vp; - int a_mode; - struct ucred *a_cred; - struct thread *a_td; - } */ *ap; -{ - struct pfsnode *pfs =3D VTOPFS(ap->a_vp); - struct proc *p1, *p2; - int error =3D 0; - - p2 =3D PFIND(pfs->pfs_pid); - if (p2 =3D=3D NULL) - return (ENOENT); - if (pfs->pfs_pid && p_cansee(ap->a_td->td_proc, p2)) { - error =3D ENOENT; - goto out; - } - - switch (pfs->pfs_type) { - case Pmem: - if (((pfs->pfs_flags & FWRITE) && (ap->a_mode & O_EXCL)) || - ((pfs->pfs_flags & O_EXCL) && (ap->a_mode & FWRITE))) { - error =3D EBUSY; - goto out; - } - - p1 =3D ap->a_td->td_proc; - error =3D p_candebug(p1, p2); - if (error) - return (error); - - if (ap->a_mode & FWRITE) - pfs->pfs_flags =3D ap->a_mode & (FWRITE|O_EXCL); - - default: - break; - } -out: - PROC_UNLOCK(p2); - return (error); -} - -/* - * close the pfsnode (vp) after doing i/o. - * (vp) is not locked on entry or exit. - * - * nothing to do for procfs other than undo - * any exclusive open flag (see _open above). - */ -static int -procfs_close(ap) - struct vop_close_args /* { - struct vnode *a_vp; - int a_fflag; - struct ucred *a_cred; - struct thread *a_td; - } */ *ap; -{ - struct pfsnode *pfs =3D VTOPFS(ap->a_vp); - struct proc *p; - - switch (pfs->pfs_type) { - case Pmem: - if ((ap->a_fflag & FWRITE) && (pfs->pfs_flags & O_EXCL)) - pfs->pfs_flags &=3D ~(FWRITE|O_EXCL); - /* - * If this is the last close, then it checks to see if - * the target process has PF_LINGER set in p_pfsflags, - * if this is *not* the case, then the process' stop flags - * are cleared, and the process is woken up. This is - * to help prevent the case where a process has been - * told to stop on an event, but then the requesting process - * has gone away or forgotten about it. - */ - if ((ap->a_vp->v_usecount < 2) && (p =3D pfind(pfs->pfs_pid))) { - if (!(p->p_pfsflags & PF_LINGER)) { - p->p_stops =3D 0; - p->p_step =3D 0; - wakeup(&p->p_step); - } - PROC_UNLOCK(p); - } - break; - default: - break; - } - - return (0); -} - -/* - * do an ioctl operation on a pfsnode (vp). - * (vp) is not locked on entry or exit. - */ -static int -procfs_ioctl(ap) - struct vop_ioctl_args *ap; -{ - struct pfsnode *pfs =3D VTOPFS(ap->a_vp); - struct proc *procp, *p; - int error; - int signo; - struct procfs_status *psp; - unsigned char flags; - - p =3D ap->a_td->td_proc; - procp =3D pfind(pfs->pfs_pid); - if (procp =3D=3D NULL) { - return ENOTTY; - } - - if ((error =3D p_candebug(p, procp))) { - PROC_UNLOCK(procp); - return (error =3D=3D ESRCH ? ENOENT : error); - } - - switch (ap->a_command) { - case PIOCBIS: - procp->p_stops |=3D *(unsigned int*)ap->a_data; - break; - case PIOCBIC: - procp->p_stops &=3D ~*(unsigned int*)ap->a_data; - break; - case PIOCSFL: - /* - * NFLAGS is "non-suser_xxx flags" -- currently, only - * PFS_ISUGID ("ignore set u/g id"); - */ -#define NFLAGS (PF_ISUGID) - flags =3D (unsigned char)*(unsigned int*)ap->a_data; - if (flags & NFLAGS && (error =3D suser(p))) { - PROC_UNLOCK(procp); - return error; - } - procp->p_pfsflags =3D flags; - break; - case PIOCGFL: - *(unsigned int*)ap->a_data =3D (unsigned int)procp->p_pfsflags; - break; - case PIOCSTATUS: - psp =3D (struct procfs_status *)ap->a_data; - psp->state =3D (procp->p_step =3D=3D 0); - psp->flags =3D procp->p_pfsflags; - psp->events =3D procp->p_stops; - if (procp->p_step) { - psp->why =3D procp->p_stype; - psp->val =3D procp->p_xstat; - } else { - psp->why =3D psp->val =3D 0; /* Not defined values */ - } - break; - case PIOCWAIT: - psp =3D (struct procfs_status *)ap->a_data; - if (procp->p_step =3D=3D 0) { - error =3D msleep(&procp->p_stype, &procp->p_mtx, PWAIT | PCATCH, - "piocwait", 0); - if (error) { - PROC_UNLOCK(procp); - return error; - } - } - psp->state =3D 1; /* It stopped */ - psp->flags =3D procp->p_pfsflags; - psp->events =3D procp->p_stops; - psp->why =3D procp->p_stype; /* why it stopped */ - psp->val =3D procp->p_xstat; /* any extra info */ - break; - case PIOCCONT: /* Restart a proc */ - if (procp->p_step =3D=3D 0) { - PROC_UNLOCK(procp); - return EINVAL; /* Can only start a stopped process */ - } - if ((signo =3D *(int*)ap->a_data) !=3D 0) { - if (signo >=3D NSIG || signo <=3D 0) { - PROC_UNLOCK(procp); - return EINVAL; - } - psignal(procp, signo); - } - procp->p_step =3D 0; - wakeup(&procp->p_step); - break; - default: - PROC_UNLOCK(procp); - return (ENOTTY); - } - PROC_UNLOCK(procp); - return 0; -} - -/* - * _reclaim is called when getnewvnode() - * wants to make use of an entry on the vnode - * free list. at this time the filesystem needs - * to free any private data and remove the node - * from any private lists. - */ -static int -procfs_reclaim(ap) - struct vop_reclaim_args /* { - struct vnode *a_vp; - } */ *ap; -{ - - return (procfs_freevp(ap->a_vp)); -} - -/* - * _print is used for debugging. - * just print a readable description - * of (vp). - */ -static int -procfs_print(ap) - struct vop_print_args /* { - struct vnode *a_vp; - } */ *ap; -{ - struct pfsnode *pfs =3D VTOPFS(ap->a_vp); - - printf("tag VT_PROCFS, type %d, pid %ld, mode %x, flags %lx\n", - pfs->pfs_type, (long)pfs->pfs_pid, pfs->pfs_mode, pfs->pfs_flags); - return (0); -} - -/* - * generic entry point for unsupported operations - */ -static int -procfs_badop() -{ - - return (EIO); -} - -/* - * Invent attributes for pfsnode (vp) and store - * them in (vap). - * Directories lengths are returned as zero since - * any real length would require the genuine size - * to be computed, and nothing cares anyway. - * - * this is relatively minimal for procfs. - */ -static int -procfs_getattr(ap) - struct vop_getattr_args /* { - struct vnode *a_vp; - struct vattr *a_vap; - struct ucred *a_cred; - struct thread *a_td; - } */ *ap; -{ - struct pfsnode *pfs =3D VTOPFS(ap->a_vp); - struct vattr *vap =3D ap->a_vap; - struct proc *procp; - int error; - - /* - * First make sure that the process and its credentials=20 - * still exist. - */ - switch (pfs->pfs_type) { - case Proot: - case Pcurproc: - procp =3D NULL; - break; - - default: - procp =3D PFIND(pfs->pfs_pid); - if (procp =3D=3D NULL) - return (ENOENT); - if (procp->p_ucred =3D=3D NULL) { - PROC_UNLOCK(procp); - return (ENOENT); - } - - if (p_cansee(ap->a_td->td_proc, procp)) { - PROC_UNLOCK(procp); - return (ENOENT); - } - PROC_UNLOCK(procp); - } - - error =3D 0; - - /* start by zeroing out the attributes */ - VATTR_NULL(vap); - - /* next do all the common fields */ - vap->va_type =3D ap->a_vp->v_type; - vap->va_mode =3D pfs->pfs_mode; - vap->va_fileid =3D pfs->pfs_fileno; - vap->va_flags =3D 0; - vap->va_blocksize =3D PAGE_SIZE; - vap->va_bytes =3D vap->va_size =3D 0; - vap->va_fsid =3D ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; - - /* - * Make all times be current TOD. - * It would be possible to get the process start - * time from the p_stat structure, but there's - * no "file creation" time stamp anyway, and the - * p_stat structure is not addressible if u. gets - * swapped out for that process. - */ - nanotime(&vap->va_ctime); - vap->va_atime =3D vap->va_mtime =3D vap->va_ctime; - - /* - * If the process has exercised some setuid or setgid - * privilege, then rip away read/write permission so - * that only root can gain access. - */ - switch (pfs->pfs_type) { - case Pctl: - case Pregs: - case Pfpregs: - case Pdbregs: - case Pmem: - PROC_LOCK(procp); - if (procp->p_flag & P_SUGID) - vap->va_mode &=3D ~((VREAD|VWRITE)| - ((VREAD|VWRITE)>>3)| - ((VREAD|VWRITE)>>6)); - PROC_UNLOCK(procp); - break; - default: - break; - } - - /* - * now do the object specific fields - * - * The size could be set from struct reg, but it's hardly - * worth the trouble, and it puts some (potentially) machine - * dependent data into this machine-independent code. If it - * becomes important then this function should break out into - * a per-file stat function in the corresponding .c file. - */ - - vap->va_nlink =3D 1; - if (procp) { - PROC_LOCK(procp); - vap->va_uid =3D procp->p_ucred->cr_uid; - vap->va_gid =3D procp->p_ucred->cr_gid; - PROC_UNLOCK(procp); - } - - switch (pfs->pfs_type) { - case Proot: - /* - * Set nlink to 1 to tell fts(3) we don't actually know. - */ - vap->va_nlink =3D 1; - vap->va_uid =3D 0; - vap->va_gid =3D 0; - vap->va_size =3D vap->va_bytes =3D DEV_BSIZE; - break; - - case Pcurproc: { - char buf[16]; /* should be enough */ - vap->va_uid =3D 0; - vap->va_gid =3D 0; - vap->va_size =3D vap->va_bytes =3D - snprintf(buf, sizeof(buf), "%ld", (long)curproc->p_pid); - break; - } - - case Pproc: - vap->va_nlink =3D nproc_targets; - vap->va_size =3D vap->va_bytes =3D DEV_BSIZE; - break; - - case Pfile: { - char *fullpath, *freepath; - error =3D textvp_fullpath(procp, &fullpath, &freepath); - if (error =3D=3D 0) { - vap->va_size =3D strlen(fullpath); - free(freepath, M_TEMP); - } else { - vap->va_size =3D sizeof("unknown") - 1; - error =3D 0; - } - vap->va_bytes =3D vap->va_size; - break; - } - - case Pmem: - /* - * If we denied owner access earlier, then we have to - * change the owner to root - otherwise 'ps' and friends - * will break even though they are setgid kmem. *SIGH* - * XXX: ps and friends are no longer setgid kmem, why - * is this needed? - */ - PROC_LOCK(procp); - if (procp->p_flag & P_SUGID) - vap->va_uid =3D 0; - else - vap->va_uid =3D procp->p_ucred->cr_uid; - PROC_UNLOCK(procp); - break; - - case Pregs: - vap->va_bytes =3D vap->va_size =3D sizeof(struct reg); - break; - - case Pfpregs: - vap->va_bytes =3D vap->va_size =3D sizeof(struct fpreg); - break; - - case Pdbregs: - vap->va_bytes =3D vap->va_size =3D sizeof(struct dbreg); - break; - - case Ptype: - case Pmap: - case Pctl: - case Pstatus: - case Pnote: - case Pnotepg: - case Pcmdline: - case Prlimit: - break; - - default: - panic("procfs_getattr"); - } - - return (error); -} - -static int -procfs_setattr(ap) - struct vop_setattr_args /* { - struct vnode *a_vp; - struct vattr *a_vap; - struct ucred *a_cred; - struct thread *a_td; - } */ *ap; -{ - - if (ap->a_vap->va_flags !=3D VNOVAL) - return (EOPNOTSUPP); - - /* - * just fake out attribute setting - * it's not good to generate an error - * return, otherwise things like creat() - * will fail when they try to set the - * file length to 0. worse, this means - * that echo $note > /proc/$pid/note will fail. - */ - - return (0); -} - -/* - * implement access checking. - * - * actually, the check for super-user is slightly - * broken since it will allow read access to write-only - * objects. this doesn't cause any particular trouble - * but does mean that the i/o entry points need to check - * that the operation really does make sense. - */ -static int -procfs_access(ap) - struct vop_access_args /* { - struct vnode *a_vp; - int a_mode; - struct ucred *a_cred; - struct thread *a_td; - } */ *ap; -{ - struct pfsnode *pfs =3D VTOPFS(ap->a_vp); - struct vnode *vp =3D ap->a_vp; - struct proc *procp; - struct vattr *vap; - struct vattr vattr; - int error; - - switch (pfs->pfs_type) { - case Proot: - case Pcurproc: - break; - default: - procp =3D PFIND(pfs->pfs_pid); - if (procp =3D=3D NULL) - return (ENOENT); - if (p_cansee(ap->a_td->td_proc, procp)) { - PROC_UNLOCK(procp); - return (ENOENT); - } - PROC_UNLOCK(procp); - } - - vap =3D &vattr; - error =3D VOP_GETATTR(vp, vap, ap->a_cred, ap->a_td); - if (error) - return (error); - - return (vaccess(vp->v_type, vap->va_mode, vap->va_uid, vap->va_gid, - ap->a_mode, ap->a_cred, NULL)); -} - -/* - * lookup. this is incredibly complicated in the - * general case, however for most pseudo-filesystems - * very little needs to be done. - * - * unless you want to get a migraine, just make sure your - * filesystem doesn't do any locking of its own. otherwise - * read and inwardly digest ufs_lookup(). - */ -static int -procfs_lookup(ap) - struct vop_lookup_args /* { - struct vnode * a_dvp; - struct vnode ** a_vpp; - struct componentname * a_cnp; - } */ *ap; -{ - struct componentname *cnp =3D ap->a_cnp; - struct vnode **vpp =3D ap->a_vpp; - struct vnode *dvp =3D ap->a_dvp; - char *pname =3D cnp->cn_nameptr; - struct proc *curp =3D cnp->cn_thread->td_proc; - struct proc_target *pt; - pid_t pid; - struct pfsnode *pfs; - struct proc *p; - int i; - struct thread *td; - - *vpp =3D NULL; - - if (cnp->cn_nameiop =3D=3D DELETE || cnp->cn_nameiop =3D=3D RENAME || - cnp->cn_nameiop =3D=3D CREATE) - return (EROFS); - - if (cnp->cn_namelen =3D=3D 1 && *pname =3D=3D '.') { - *vpp =3D dvp; - VREF(dvp); - /* vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY, curp); */ - return (0); - } - - pfs =3D VTOPFS(dvp); - switch (pfs->pfs_type) { - case Proot: - if (cnp->cn_flags & ISDOTDOT) - return (EIO); - - if (CNEQ(cnp, "curproc", 7)) - return (procfs_allocvp(dvp->v_mount, vpp, 0, Pcurproc)); - - pid =3D atopid(pname, cnp->cn_namelen); - if (pid =3D=3D NO_PID) - break; - - p =3D PFIND(pid); - if (p =3D=3D NULL) - break; - - if (p_cansee(curp, p)) { - PROC_UNLOCK(p); - break; - } - PROC_UNLOCK(p); - - return (procfs_allocvp(dvp->v_mount, vpp, pid, Pproc)); - - case Pproc: - if (cnp->cn_flags & ISDOTDOT) - return (procfs_root(dvp->v_mount, vpp)); - - p =3D PFIND(pfs->pfs_pid); - td =3D &p->p_thread; /* XXXKSE */ - if (p =3D=3D NULL) - break; - - for (pt =3D proc_targets, i =3D 0; i < nproc_targets; pt++, i++) { - if (cnp->cn_namelen =3D=3D pt->pt_namlen && - bcmp(pt->pt_name, pname, cnp->cn_namelen) =3D=3D 0 && - (pt->pt_valid =3D=3D NULL || (*pt->pt_valid)(td))) - goto found; - } - PROC_UNLOCK(p); - break; - found: - PROC_UNLOCK(p); - return (procfs_allocvp(dvp->v_mount, vpp, pfs->pfs_pid, - pt->pt_pfstype)); - - default: - return (ENOTDIR); - } - - return (cnp->cn_nameiop =3D=3D LOOKUP ? ENOENT : EROFS); -} - -/* - * Does this process have a text file? - */ -int -procfs_validfile(td) - struct thread *td; -{ - - return (td->td_proc->p_textvp !=3D NULLVP); -} - -/* - * readdir() returns directory entries from pfsnode (vp). - * - * We generate just one directory entry at a time, as it would probably - * not pay off to buffer several entries locally to save uiomove calls. - */ -static int -procfs_readdir(ap) - struct vop_readdir_args /* { - struct vnode *a_vp; - struct uio *a_uio; - struct ucred *a_cred; - int *a_eofflag; - int *a_ncookies; - u_long **a_cookies; - } */ *ap; -{ - struct uio *uio =3D ap->a_uio; - struct dirent d; - struct dirent *dp =3D &d; - struct pfsnode *pfs; - int count, error, i, off; - static u_int delen; - struct thread *td; - - if (!delen) { - - d.d_namlen =3D PROCFS_NAMELEN; - delen =3D GENERIC_DIRSIZ(&d); - } - - pfs =3D VTOPFS(ap->a_vp); - - off =3D (int)uio->uio_offset; - if (off !=3D uio->uio_offset || off < 0 ||=20 - off % delen !=3D 0 || uio->uio_resid < delen) - return (EINVAL); - - error =3D 0; - count =3D 0; - i =3D off / delen; - - switch (pfs->pfs_type) { - /* - * this is for the process-specific sub-directories. - * all that is needed to is copy out all the entries - * from the procent[] table (top of this file). - */ - case Pproc: { - struct proc *p; - struct proc_target *pt; - - p =3D PFIND(pfs->pfs_pid); - td =3D &p->p_thread; /* XXXKSE */ - if (p =3D=3D NULL) - break; - if (p_cansee(curthread->td_proc, p)) { - PROC_UNLOCK(p); - break; - } - - for (pt =3D &proc_targets[i]; - uio->uio_resid >=3D delen && i < nproc_targets; pt++, i++) { - if (pt->pt_valid && (*pt->pt_valid)(td) =3D=3D 0) - continue; - - dp->d_reclen =3D delen; - dp->d_fileno =3D PROCFS_FILENO(pfs->pfs_pid, pt->pt_pfstype); - dp->d_namlen =3D pt->pt_namlen; - bcopy(pt->pt_name, dp->d_name, pt->pt_namlen + 1); - dp->d_type =3D pt->pt_type; - - PROC_UNLOCK(p); - if ((error =3D uiomove((caddr_t)dp, delen, uio)) !=3D 0) - break; - PROC_LOCK(p); - } - PROC_UNLOCK(p); - - break; - } - - /* - * this is for the root of the procfs filesystem - * what is needed is a special entry for "curproc" - * followed by an entry for each process on allproc -#ifdef PROCFS_ZOMBIE - * and zombproc. -#endif - */ - - case Proot: { -#ifdef PROCFS_ZOMBIE - int doingzomb =3D 0; -#endif - int pcnt =3D 0; - struct proc *p; - - sx_slock(&allproc_lock); - p =3D LIST_FIRST(&allproc); - for (; p && uio->uio_resid >=3D delen; i++, pcnt++) { - bzero((char *) dp, delen); - dp->d_reclen =3D delen; - - switch (i) { - case 0: /* `.' */ - case 1: /* `..' */ - dp->d_fileno =3D PROCFS_FILENO(0, Proot); - dp->d_namlen =3D i + 1; - bcopy("..", dp->d_name, dp->d_namlen); - dp->d_name[i + 1] =3D '\0'; - dp->d_type =3D DT_DIR; - break; - - case 2: - dp->d_fileno =3D PROCFS_FILENO(0, Pcurproc); - dp->d_namlen =3D 7; - bcopy("curproc", dp->d_name, 8); - dp->d_type =3D DT_LNK; - break; - - default: - while (pcnt < i) { - p =3D LIST_NEXT(p, p_list); - if (p =3D=3D NULL) - goto done; - if (p_cansee(curthread->td_proc, p)) - continue; - pcnt++; - } - while (p_cansee(curthread->td_proc, p)) { - p =3D LIST_NEXT(p, p_list); - if (p =3D=3D NULL) - goto done; - } - dp->d_fileno =3D PROCFS_FILENO(p->p_pid, Pproc); - dp->d_namlen =3D sprintf(dp->d_name, "%ld", - (long)p->p_pid); - dp->d_type =3D DT_DIR; - p =3D LIST_NEXT(p, p_list); - break; - } - - if ((error =3D uiomove((caddr_t)dp, delen, uio)) !=3D 0) - break; - } - done: - -#ifdef PROCFS_ZOMBIE - if (p =3D=3D NULL && doingzomb =3D=3D 0) { - doingzomb =3D 1; - p =3D LIST_FIRST(&zombproc); - goto again; - } -#endif - - sx_sunlock(&allproc_lock); - break; - - } - - default: - error =3D ENOTDIR; - break; - } - - uio->uio_offset =3D i * delen; - - return (error); -} - -/* - * readlink reads the link of `curproc' or `file' - */ -static int -procfs_readlink(ap) - struct vop_readlink_args *ap; -{ - char buf[16]; /* should be enough */ - struct proc *procp; - struct vnode *vp =3D ap->a_vp; - struct pfsnode *pfs =3D VTOPFS(vp); - char *fullpath, *freepath; - int error, len; - - switch (pfs->pfs_type) { - case Pcurproc: - if (pfs->pfs_fileno !=3D PROCFS_FILENO(0, Pcurproc)) - return (EINVAL); - - len =3D snprintf(buf, sizeof(buf), "%ld", (long)curproc->p_pid); - - return (uiomove(buf, len, ap->a_uio)); - /* - * There _should_ be no way for an entire process to disappear - * from under us... - */ - case Pfile: - procp =3D PFIND(pfs->pfs_pid); - if (procp =3D=3D NULL || procp->p_ucred =3D=3D NULL) { - if (procp !=3D NULL) - PROC_UNLOCK(procp); - printf("procfs_readlink: pid %d disappeared\n", - pfs->pfs_pid); - return (uiomove("unknown", sizeof("unknown") - 1, - ap->a_uio)); - } - PROC_UNLOCK(procp); - error =3D textvp_fullpath(procp, &fullpath, &freepath); - if (error !=3D 0) - return (uiomove("unknown", sizeof("unknown") - 1, - ap->a_uio)); - error =3D uiomove(fullpath, strlen(fullpath), ap->a_uio); - free(freepath, M_TEMP); - return (error); - default: - return (EINVAL); - } -} - -/* - * convert decimal ascii to pid_t - */ -static pid_t -atopid(b, len) - const char *b; - u_int len; -{ - pid_t p =3D 0; - - while (len--) { - char c =3D *b++; - if (c < '0' || c > '9') - return (NO_PID); - p =3D 10 * p + (c - '0'); - if (p > PID_MAX) - return (NO_PID); - } - - return (p); -} - -/* - * procfs vnode operations. - */ -vop_t **procfs_vnodeop_p; -static struct vnodeopv_entry_desc procfs_vnodeop_entries[] =3D { - { &vop_default_desc, (vop_t *) vop_defaultop }, - { &vop_access_desc, (vop_t *) procfs_access }, - { &vop_advlock_desc, (vop_t *) procfs_badop }, - { &vop_close_desc, (vop_t *) procfs_close }, - { &vop_create_desc, (vop_t *) procfs_badop }, - { &vop_getattr_desc, (vop_t *) procfs_getattr }, - { &vop_link_desc, (vop_t *) procfs_badop }, - { &vop_lookup_desc, (vop_t *) procfs_lookup }, - { &vop_mkdir_desc, (vop_t *) procfs_badop }, - { &vop_mknod_desc, (vop_t *) procfs_badop }, - { &vop_open_desc, (vop_t *) procfs_open }, - { &vop_pathconf_desc, (vop_t *) vop_stdpathconf }, - { &vop_print_desc, (vop_t *) procfs_print }, - { &vop_read_desc, (vop_t *) procfs_rw }, - { &vop_readdir_desc, (vop_t *) procfs_readdir }, - { &vop_readlink_desc, (vop_t *) procfs_readlink }, - { &vop_reclaim_desc, (vop_t *) procfs_reclaim }, - { &vop_remove_desc, (vop_t *) procfs_badop }, - { &vop_rename_desc, (vop_t *) procfs_badop }, - { &vop_rmdir_desc, (vop_t *) procfs_badop }, - { &vop_setattr_desc, (vop_t *) procfs_setattr }, - { &vop_symlink_desc, (vop_t *) procfs_badop }, - { &vop_write_desc, (vop_t *) procfs_rw }, - { &vop_ioctl_desc, (vop_t *) procfs_ioctl }, - { NULL, NULL } -}; -static struct vnodeopv_desc procfs_vnodeop_opv_desc =3D - { &procfs_vnodeop_p, procfs_vnodeop_entries }; - -VNODEOP_SET(procfs_vnodeop_opv_desc); Index: sys/modules/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/modules/Makefile,v retrieving revision 1.213 diff -u -r1.213 Makefile --- sys/modules/Makefile 28 Oct 2001 04:34:24 -0000 1.213 +++ sys/modules/Makefile 29 Oct 2001 18:56:44 -0000 @@ -61,7 +61,6 @@ nullfs \ pcn \ portalfs \ - procfs \ ${_random} \ rl \ rp \ Index: sys/modules/fs/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/modules/fs/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- sys/modules/fs/Makefile 11 Jun 2001 21:57:18 -0000 1.3 +++ sys/modules/fs/Makefile 1 Jul 2001 22:33:41 -0000 @@ -2,6 +2,7 @@ =20 SUBDIR =3D SUBDIR +=3D linprocfs +SUBDIR +=3D procfs SUBDIR +=3D pseudofs =20 .include Index: sys/modules/fs/procfs/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: sys/modules/fs/procfs/Makefile diff -N sys/modules/fs/procfs/Makefile --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/modules/fs/procfs/Makefile 5 Oct 2001 11:07:29 -0000 @@ -0,0 +1,19 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../fs/procfs + +KMOD=3D procfs +SRCS=3D vnode_if.h \ + procfs_ctl.c \ + procfs_dbregs.c \ + procfs_fpregs.c \ + procfs_map.c \ + procfs_mem.c \ + procfs_note.c \ + procfs_regs.c \ + procfs_rlimit.c \ + procfs_status.c \ + procfs_type.c \ + procfs.c + +.include --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 30 8:50:44 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 ED24B37B405; Tue, 30 Oct 2001 08:50:42 -0800 (PST) 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 f9UGof0H009849; Tue, 30 Oct 2001 09:50:41 -0700 (MST) Message-Id: <200110301650.f9UGof0H009849@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Giorgos Keramidas Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks In-Reply-To: Message from Giorgos Keramidas of "Tue, 30 Oct 2001 01:21:43 +0200." <20011030012143.B32738@hades.hell.gr> Date: Tue, 30 Oct 2001 09:50:41 -0700 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 > Well, Lyndon, this is quickly turning into a flamefest. 64 bit time_t is a flamefest. This, OTOH, is a very reasonable discussion. > It really is not worth it, is it? Without discussion there would never be change. I was curious to discover the rational for keeping the GNU names for the C compiler (but not the other GNU tools). I'm not sure I really received an answer, and maybe that's the answer in itself. But you're right - this horse is dead. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 30 9:32:13 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 D022737B409 for ; Tue, 30 Oct 2001 09:32:10 -0800 (PST) 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 f9UHWAM62686 for ; Tue, 30 Oct 2001 09:32:10 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 59A5F39F4; Tue, 30 Oct 2001 09:32:10 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bruce Evans Cc: Garance A Drosihn , Julian Elischer , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011030210506.G1406-100000@delplex.bde.org> Date: Tue, 30 Oct 2001 09:32:10 -0800 From: Peter Wemm Message-Id: <20011030173210.59A5F39F4@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 Bruce Evans wrote: > On Mon, 29 Oct 2001, Peter Wemm wrote: > > > ... UFS does not have future dates ... > > Script started on Tue Oct 30 21:04:39 2001 > ttyv7:bde@delplex:/tmp> touch -t 203801011230 foo > ttyv7:bde@delplex:/tmp> ls -l foo > -rw-r--r-- 1 bde wheel 0 Jan 1 2038 foo > ttyv7:bde@delplex:/tmp> exit I know that.. This is a contrived example. atime, mtime, ctime are defined as the time that the file was last operated on. One does not do 30-year mortgage calculations using ufs file timestamps. The only dates they *need* to support is "a long time ago" through "now". 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 30 10: 0:31 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 8E73D37B406 for ; Tue, 30 Oct 2001 10:00:27 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA31516; Tue, 30 Oct 2001 09:49:29 -0800 (PST) Date: Tue, 30 Oct 2001 09:49:27 -0800 (PST) From: Julian Elischer To: Peter Wemm Cc: Bruce Evans , Garance A Drosihn , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011030173210.59A5F39F4@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 Tue, 30 Oct 2001, Peter Wemm wrote: > Bruce Evans wrote: > > On Mon, 29 Oct 2001, Peter Wemm wrote: > > > > > ... UFS does not have future dates ... > > > > Script started on Tue Oct 30 21:04:39 2001 > > ttyv7:bde@delplex:/tmp> touch -t 203801011230 foo > > ttyv7:bde@delplex:/tmp> ls -l foo > > -rw-r--r-- 1 bde wheel 0 Jan 1 2038 foo > > ttyv7:bde@delplex:/tmp> exit > > I know that.. This is a contrived example. atime, mtime, ctime are defined > as the time that the file was last operated on. One does not do 30-year > mortgage calculations using ufs file timestamps. The only dates they *need* > to support is "a long time ago" through "now". where "a long time ago" is NOT before 1970.... I see not reason that the timestamps should be signed.. > > 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 30 10: 0:41 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 6A17637B403 for ; Tue, 30 Oct 2001 10:00:38 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA31524; Tue, 30 Oct 2001 09:52:43 -0800 (PST) Date: Tue, 30 Oct 2001 09:52:43 -0800 (PST) From: Julian Elischer To: Peter Wemm Cc: Bruce Evans , Garance A Drosihn , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <20011030173210.59A5F39F4@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 Tue, 30 Oct 2001, Peter Wemm wrote: > Bruce Evans wrote: > > On Mon, 29 Oct 2001, Peter Wemm wrote: > > > > > ... UFS does not have future dates ... > > > > Script started on Tue Oct 30 21:04:39 2001 > > ttyv7:bde@delplex:/tmp> touch -t 203801011230 foo > > ttyv7:bde@delplex:/tmp> ls -l foo > > -rw-r--r-- 1 bde wheel 0 Jan 1 2038 foo > > ttyv7:bde@delplex:/tmp> exit > > I know that.. This is a contrived example. atime, mtime, ctime are defined > as the time that the file was last operated on. One does not do 30-year > mortgage calculations using ufs file timestamps. The only dates they *need* > to support is "a long time ago" through "now". One added note however.. I am expecting that there will be embedded systems being deployed NOW that will be in service in 2038. I have personally seen systems I installed in 1982 still running with NO sign of being replaced.. (probably will go on controlling stuff until the building is pulled down around them). If they have flash filesystems with timestamps it might be nice if they didn't go wierd in 2038.. > > 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 30 10: 3: 9 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 D7DBE37B401 for ; Tue, 30 Oct 2001 10:03:01 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA20708; Tue, 30 Oct 2001 11:02:43 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id f9UI2h207970; Tue, 30 Oct 2001 11:02:43 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15326.60226.510153.799277@caddis.yogotech.com> Date: Tue, 30 Oct 2001 11:02:42 -0700 To: Julian Elischer Cc: Peter Wemm , Bruce Evans , Garance A Drosihn , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: References: <20011030173210.59A5F39F4@overcee.netplex.com.au> 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 > > > > ... UFS does not have future dates ... > > > > > > Script started on Tue Oct 30 21:04:39 2001 > > > ttyv7:bde@delplex:/tmp> touch -t 203801011230 foo > > > ttyv7:bde@delplex:/tmp> ls -l foo > > > -rw-r--r-- 1 bde wheel 0 Jan 1 2038 foo > > > ttyv7:bde@delplex:/tmp> exit > > > > I know that.. This is a contrived example. atime, mtime, ctime are defined > > as the time that the file was last operated on. One does not do 30-year > > mortgage calculations using ufs file timestamps. The only dates they *need* > > to support is "a long time ago" through "now". > > > One added note however.. I am expecting that there will be embedded > systems being deployed NOW that will be in service in 2038. If there are, and they rely on the timestamps on the filestamps, the developers must be aware of the current limitations of the timestamps on the FS. I think most folks are aware of these kinds of issues after the entire Y2K fiasco. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 30 10:33:59 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 6614037B405 for ; Tue, 30 Oct 2001 10:33:55 -0800 (PST) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.6/8.11.6) with ESMTP id f9UIXMZ41710; Tue, 30 Oct 2001 11:33:22 -0700 (MST) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200110301833.f9UIXMZ41710@hunkular.glarp.com> To: Julian Elischer Cc: Peter Wemm , Bruce Evans , Garance A Drosihn , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Tue, 30 Oct 2001 09:49:27 PST." Date: Tue, 30 Oct 2001 11:33:22 -0700 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 > I see not reason that the timestamps should be signed.. Arithmatic on timestamps will break if time_t is changed to unsigned. brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 30 10:34: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 0FA4237B403 for ; Tue, 30 Oct 2001 10:34:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9UIYeR94440; Tue, 30 Oct 2001 10:34:40 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Oct 2001 10:34:40 -0800 (PST) From: Matthew Dillon Message-Id: <200110301834.f9UIYeR94440@apollo.backplane.com> To: Bruce Evans Cc: Julian Elischer , Nate Williams , Poul-Henning Kamp , Peter Wemm , Subject: Re: 64 bit times revisited.. References: <20011030210857.R1525-100000@delplex.bde.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 Mon, 29 Oct 2001, Julian Elischer wrote: : :> and you really want us to believe that data file came form 1910? : :I simply refuted a false claim that timestamps can't be before 1970. : :> On Tue, 30 Oct 2001, Bruce Evans wrote: :> :> > On Mon, 29 Oct 2001, Julian Elischer wrote: :> > :> > > be used for multiplying the seconds scale by 4. (in UFS timestamps.. :> > > you would never write a non-normalised time to disk) :> > > also timestamps can't be before 1970 so making it unsigned :> > > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. :> > :> > Script started on Tue Oct 30 06:55:55 2001 :> > ttyp1:bde@gamplex:/tmp> touch -t 191001011230 foo :> > ttyp1:bde@gamplex:/tmp> ls -l foo :> > -rw-r--r-- 1 bde wheel 0 Jan 1 1910 foo :> > ttyp1:bde@gamplex:/tmp> exit :> > :> > Script done on Tue Oct 30 06:56:10 2001 : :This mailing list is approaching the quality of the average newsgroup, :complete with top posting by newbies. : :Bruce We can't make time_t unsigned anyway. A huge amount of code (hundreds of instances) do delta comparisons and simply assume that time_t is signed. With it unsigned many of those comparisons would blow up (return true when they should return false). I'm about ready to give up trying to convince people that it's worth moving IA32 to 64 bit timestamps. The bigger issue, however, is what to do about 64 bit platforms. I keep finding system calls that need to be rolled. The list is now getting pretty big. I am up to 22 system calls. This means that if we are NOT going to change IA32 but we ARE going to change 64 bit architectures, then we should do it *without* rolling system calls at all which would mean having to eat any binary incompatibilities from older code. It might conceivably be worth rolling the syscalls if we were to change IA32, but if we aren't it just isn't worth it to roll the syscalls just to support pre-time-change 64 bit platforms. -Matt Matthew Dillon 7 MCOMPAT2 BSD { int wait4(int pid, int *status, int options, \ 83 MCOMPAT2 BSD { int setitimer(u_int which, struct o2itimerval *itv, \ 86 MCOMPAT2 BSD { int getitimer(u_int which, struct o2itimerval *itv); } 93 MCOMPAT2 BSD { int select(int nd, fd_set *in, fd_set *ou, \ 116 MCOMPAT2 BSD { int gettimeofday(struct o2timeval *tp, \ 117 MCOMPAT2 BSD { int getrusage(int who, struct o2rusage *rusage); } 122 MCOMPAT2 BSD { int settimeofday(struct o2timeval *tv, \ 138 COMPAT2 BSD { int utimes(char *path, struct o2timeval *tptr); } 140 MCOMPAT2 BSD { int adjtime(struct o2timeval *delta, \ 188 COMPAT2 POSIX { int stat(char *path, struct o2stat *ub); } 189 MCOMPAT2 POSIX { int fstat(int fd, struct o2stat *sb); } 190 COMPAT2 POSIX { int lstat(char *path, struct o2stat *ub); } 206 COMPAT2 BSD { int futimes(int fd, struct o2timeval *tptr); } 232 MCOMPAT2 POSIX { int clock_gettime(clockid_t clock_id, \ 233 MCOMPAT2 POSIX { int clock_settime(clockid_t clock_id, \ 234 MCOMPAT2 POSIX { int clock_getres(clockid_t clock_id, \ 240 MCOMPAT2 POSIX { int nanosleep(const struct o2timespec *rqtp, \ 276 COMPAT2 BSD { int lutimes(char *path, struct o2timeval *tptr); } 299 COMPAT2 BSD { int fhstat(const struct fhandle *u_fhp, struct o2stat *sb); } 315 COMPAT2 BSD { int aio_suspend(struct aiocb * const * aiocbp, int nent, const struct o2timespec *timeout); } 334 MCOMPAT2 POSIX { int sched_rr_get_interval (pid_t pid, struct o2timespec *interval); } 363 MCOMPAT2 BSD { int kevent(int fd, \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 30 10:45:19 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 923CA37B401 for ; Tue, 30 Oct 2001 10:45:16 -0800 (PST) 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 FAA02122; Wed, 31 Oct 2001 05:44:57 +1100 Date: Wed, 31 Oct 2001 05:43:56 +1100 (EST) From: Bruce Evans X-X-Sender: To: Peter Wemm Cc: Garance A Drosihn , Julian Elischer , Nate Williams , Subject: Re: 64 bit times revisited.. In-Reply-To: <20011030173210.59A5F39F4@overcee.netplex.com.au> Message-ID: <20011031052447.H4665-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 Tue, 30 Oct 2001, Peter Wemm wrote: > Bruce Evans wrote: > > On Mon, 29 Oct 2001, Peter Wemm wrote: > > > > > ... UFS does not have future dates ... > > > > Script started on Tue Oct 30 21:04:39 2001 > > ttyv7:bde@delplex:/tmp> touch -t 203801011230 foo > > ttyv7:bde@delplex:/tmp> ls -l foo > > -rw-r--r-- 1 bde wheel 0 Jan 1 2038 foo > > ttyv7:bde@delplex:/tmp> exit > > I know that.. This is a contrived example. atime, mtime, ctime are defined > as the time that the file was last operated on. One does not do 30-year > mortgage calculations using ufs file timestamps. The only dates they *need* > to support is "a long time ago" through "now". Sure it's contrived, but it shows that UFS does have future dates. In fact, the timestamps for writable POSIX filesystems are implicitly specified to be able to represent all possible values of a time_t (including the invalid one (time_t)-1!), because all these values can be requested using utime(2) and there is no documented way that utime(2) can fail due to invalid times. This currently "just works" for ffs at least, because the timestamps really are time_t's. The timestamps for writable BSD filesystems are also implicitly specified to be able to represent all possible values of a long, becaue of the same considerations for utimes(2). This currently just doesn't work for ffs on alphas at least. Proposterously distant times passed by utimes(2) cause overflow in TIMEVAL_TO_TIMESPEC(). 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 30 10:52:33 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 EE29F37B405 for ; Tue, 30 Oct 2001 10:52:28 -0800 (PST) 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 f9UIqHI118762; Tue, 30 Oct 2001 13:52:17 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Tue, 30 Oct 2001 13:52:14 -0500 To: Julian Elischer , Peter Wemm From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Cc: Bruce Evans , Nate Williams , 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 9:52 AM -0800 10/30/01, Julian Elischer wrote: >One added note however.. I am expecting that there will be embedded >systems being deployed NOW that will be in service in 2038. Let us say that is true. All such systems deployed before this second in time -> this one here <- will not work in 2038, because freebsd at this time does not support it. I have no objection if someone wants to do the work to change UFS to use unsigned timestamps for that field, but I expect it'll take at least a few months to implement that and DEBUG it for real. That because the only way to really debug such a change is to run your system with a date which is AFTER 2038, and to do that for a few months. That's the only way to get real-world experience of what will and what will not work if that field is changed to be unsigned. So, not only will today's embedded systems not work, but it'll be a few more months (or at least a few weeks) before any 2038-safe embedded systems can be deployed. How much longer will it be before we have UFS2 and a more-permanent solution? Another year? Two? So you are really only gaining a two-year span where embedded systems will work after 2038, and 2038 is 37 years from now... Still, if someone wants to do that work, then I'm all for the idea (honest, I am!). The only place where I really start objecting is when we start stealing bits from other fields, and thus spreading a single value over several different spots in a 'struct'. Sounds like Julian is volunteering to do the work... :-) -- 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 Tue Oct 30 11:40:39 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 99BEF37B403 for ; Tue, 30 Oct 2001 11:40:34 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA31997; Tue, 30 Oct 2001 11:20:13 -0800 (PST) Date: Tue, 30 Oct 2001 11:20:11 -0800 (PST) From: Julian Elischer To: Brad Huntting Cc: Peter Wemm , Bruce Evans , Garance A Drosihn , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <200110301833.f9UIXMZ41710@hunkular.glarp.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 can you give an example? On Tue, 30 Oct 2001, Brad Huntting wrote: > > > I see not reason that the timestamps should be signed.. > > Arithmatic on timestamps will break if time_t is changed to unsigned. > > > brad > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 30 11:41: 3 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 150F137B407 for ; Tue, 30 Oct 2001 11:40:56 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA32013; Tue, 30 Oct 2001 11:21:40 -0800 (PST) Date: Tue, 30 Oct 2001 11:21:39 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Bruce Evans , Nate Williams , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <200110301834.f9UIYeR94440@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 On Tue, 30 Oct 2001, Matthew Dillon wrote: > :On Mon, 29 Oct 2001, Julian Elischer wrote: > : > :> and you really want us to believe that data file came form 1910? > : > :I simply refuted a false claim that timestamps can't be before 1970. > : > :> On Tue, 30 Oct 2001, Bruce Evans wrote: > :> > :> > On Mon, 29 Oct 2001, Julian Elischer wrote: > :> > > :> > > be used for multiplying the seconds scale by 4. (in UFS timestamps.. > :> > > you would never write a non-normalised time to disk) > :> > > also timestamps can't be before 1970 so making it unsigned > :> > > allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. > :> > > :> > Script started on Tue Oct 30 06:55:55 2001 > :> > ttyp1:bde@gamplex:/tmp> touch -t 191001011230 foo > :> > ttyp1:bde@gamplex:/tmp> ls -l foo > :> > -rw-r--r-- 1 bde wheel 0 Jan 1 1910 foo > :> > ttyp1:bde@gamplex:/tmp> exit > :> > > :> > Script done on Tue Oct 30 06:56:10 2001 > : > :This mailing list is approaching the quality of the average newsgroup, > :complete with top posting by newbies. > : > :Bruce > > We can't make time_t unsigned anyway. A huge amount of code > (hundreds of instances) do delta comparisons and simply assume > that time_t is signed. With it unsigned many of those comparisons > would blow up (return true when they should return false). I'm not advocating making time_t unsigned.. just the timestamp fields in the UFS inodes.. > > I'm about ready to give up trying to convince people that it's worth > moving IA32 to 64 bit timestamps. The bigger issue, however, is > what to do about 64 bit platforms. I keep finding system calls > that need to be rolled. The list is now getting pretty big. I am > up to 22 system calls. > > This means that if we are NOT going to change IA32 but we ARE going > to change 64 bit architectures, then we should do it *without* > rolling system calls at all which would mean having to eat any > binary incompatibilities from older code. It might conceivably be > worth rolling the syscalls if we were to change IA32, but if we aren't > it just isn't worth it to roll the syscalls just to support > pre-time-change 64 bit platforms. > > -Matt > Matthew Dillon > > > > 7 MCOMPAT2 BSD { int wait4(int pid, int *status, int options, \ > 83 MCOMPAT2 BSD { int setitimer(u_int which, struct o2itimerval *itv, \ > 86 MCOMPAT2 BSD { int getitimer(u_int which, struct o2itimerval *itv); } > 93 MCOMPAT2 BSD { int select(int nd, fd_set *in, fd_set *ou, \ > 116 MCOMPAT2 BSD { int gettimeofday(struct o2timeval *tp, \ > 117 MCOMPAT2 BSD { int getrusage(int who, struct o2rusage *rusage); } > 122 MCOMPAT2 BSD { int settimeofday(struct o2timeval *tv, \ > 138 COMPAT2 BSD { int utimes(char *path, struct o2timeval *tptr); } > 140 MCOMPAT2 BSD { int adjtime(struct o2timeval *delta, \ > 188 COMPAT2 POSIX { int stat(char *path, struct o2stat *ub); } > 189 MCOMPAT2 POSIX { int fstat(int fd, struct o2stat *sb); } > 190 COMPAT2 POSIX { int lstat(char *path, struct o2stat *ub); } > 206 COMPAT2 BSD { int futimes(int fd, struct o2timeval *tptr); } > 232 MCOMPAT2 POSIX { int clock_gettime(clockid_t clock_id, \ > 233 MCOMPAT2 POSIX { int clock_settime(clockid_t clock_id, \ > 234 MCOMPAT2 POSIX { int clock_getres(clockid_t clock_id, \ > 240 MCOMPAT2 POSIX { int nanosleep(const struct o2timespec *rqtp, \ > 276 COMPAT2 BSD { int lutimes(char *path, struct o2timeval *tptr); } > 299 COMPAT2 BSD { int fhstat(const struct fhandle *u_fhp, struct o2stat *sb); } > 315 COMPAT2 BSD { int aio_suspend(struct aiocb * const * aiocbp, int nent, const struct o2timespec *timeout); } > 334 MCOMPAT2 POSIX { int sched_rr_get_interval (pid_t pid, struct o2timespec *interval); } > 363 MCOMPAT2 BSD { int kevent(int fd, \ > > 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 Tue Oct 30 11:57:45 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 7503837B403 for ; Tue, 30 Oct 2001 11:57:42 -0800 (PST) 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 f9UJvUI76150; Tue, 30 Oct 2001 14:57:30 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200110301834.f9UIYeR94440@apollo.backplane.com> References: <20011030210857.R1525-100000@delplex.bde.org> <200110301834.f9UIYeR94440@apollo.backplane.com> Date: Tue, 30 Oct 2001 14:57:28 -0500 To: Matthew Dillon , Bruce Evans From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Cc: Julian Elischer , 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:34 AM -0800 10/30/01, Matthew Dillon wrote: > We can't make time_t unsigned anyway. A huge amount of code > (hundreds of instances) do delta comparisons and simply assume > that time_t is signed. With it unsigned many of those comparisons > would blow up (return true when they should return false). My understanding is that we have two debates going. One for time_t being 64-bit, and a related one for what we should do about time_t values which are stored on disk as part of UFS. It is probably way too disruptive to change the size of those fields, so those fields probably have to stay 32-bit. So then the question is "can we make those UFS fields be unsigned, so they'll last past 2038?". I don't think anyone is pushing for time_t itself to be unsigned. (someone correct me if I'm wrong... :-) > This means that if we are NOT going to change IA32 but we ARE > going to change 64 bit architectures, then we should do it > *without* rolling system calls at all which would mean having > to eat any binary incompatibilities from older code. It might > conceivably be worth rolling the syscalls if we were to change > IA32, but if we aren't it just isn't worth it to roll the > syscalls just to support pre-time-change 64 bit platforms. I think the Alpha crowd is saying that they don't want that platform to change unless IA32 also changes, at least not for 5.0-release. I do not know if it makes sense to move to 64-bit on new platforms, and then decide about rolling the system calls on older platforms at some later date... -- 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 Tue Oct 30 16:43: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.gnf.org (relay.gnf.org [208.44.31.36]) by hub.freebsd.org (Postfix) with ESMTP id 76B2637B403 for ; Tue, 30 Oct 2001 16:42:59 -0800 (PST) Received: from mail.gnf.org (smtp.gnf.org [10.0.0.11]) by relay.gnf.org (8.11.6/8.11.6) with ESMTP id f9V0gsi09834 for ; Tue, 30 Oct 2001 16:42:54 -0800 Received: by mail.gnf.org (Postfix, from userid 888) id EAE9D11E505; Tue, 30 Oct 2001 16:39:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id DE54011A577 for ; Tue, 30 Oct 2001 16:39:51 -0800 (PST) Date: Tue, 30 Oct 2001 16:39:51 -0800 (PST) From: Gordon Tetlow To: Subject: rc.d patch to test out 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 Okay, here's a link to my patch that boots enough to mount filesystems listed in critical_filesystems_beforenet. Here's what you need to do: download http://hobbes.melthusia.org/~gordont/rc_ng.diff cd /usr/src patch < /path/to/rc_ng.diff cd sbin/rcorder make && make install && make cleandir mergemaster -is Now, before you reboot your machine, you need to add some lines to your /etc/rc.conf: rc_ng="YES" # Master switch for the boot scripts critical_filesystems_beforenet="/usr /other/mnt/point" Since O'Brien was adamant on not messing too much with the boot order from NetBSD, you need to put the filesystems (esp /usr) that you want mounted since I haven't gotten to doing any network stuff yet. Here's what mine looks like: critical_filesystems_beforenet="/usr /local" Feedback please as to if this is the direction we want to go. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 30 22:57:37 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 7BCA937B403 for ; Tue, 30 Oct 2001 22:57:17 -0800 (PST) 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 f9V6vHp16257 for ; Tue, 30 Oct 2001 22:57:17 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9V6vK148391 for arch@FreeBSD.org; Tue, 30 Oct 2001 22:57:20 -0800 (PST) (envelope-from marcel) Date: Tue, 30 Oct 2001 22:57:20 -0800 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: FYI: A thought on 64-bit time_t on Alpha Message-ID: <20011030225720.A39348@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Gang, We all seem to be of the opinion that the 64-bit archs should have a 64-bit time_t. The question that is unanswered at this time is whether this includes the Alpha. What I want to avoid is that Alpha will continue to be the odd one even if it's not anymore the only 64-bit arch (or even the only "other" arch). For some reason I don't think it's a good idea to have the Alpha cuddle up with i386. Not only will it be the odd one among the 64-bit archs, it will not stop being the odd one in the 32-bit camp. So, whatever we decide, let's keep in mind that it can harm the Alpha too if we treat it as an 32-bit arch and not have time_t be 64-bit. From where I'm standing, it looks that the pain of changing the Alpha is more like a short painful sting, compared to the long and nagging itch of not changing time_t. I'd rather have the sting... Just FYI, -- 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 Tue Oct 30 23:59:45 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 2D76237B403 for ; Tue, 30 Oct 2001 23:59:41 -0800 (PST) Received: (qmail 47841 invoked from network); 31 Oct 2001 07:59:25 -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 ; 31 Oct 2001 07:59: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: <20011030225720.A39348@dhcp01.pn.xcllnt.net> Date: Tue, 30 Oct 2001 23:59:22 -0800 (PST) From: John Baldwin To: Marcel Moolenaar Subject: RE: FYI: A thought on 64-bit time_t on Alpha 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 On 31-Oct-01 Marcel Moolenaar wrote: > Gang, > > We all seem to be of the opinion that the 64-bit archs should > have a 64-bit time_t. The question that is unanswered at this > time is whether this includes the Alpha. > > What I want to avoid is that Alpha will continue to be the odd > one even if it's not anymore the only 64-bit arch (or even the > only "other" arch). For some reason I don't think it's a good > idea to have the Alpha cuddle up with i386. Not only will it > be the odd one among the 64-bit archs, it will not stop being > the odd one in the 32-bit camp. > > So, whatever we decide, let's keep in mind that it can harm the > Alpha too if we treat it as an 32-bit arch and not have time_t > be 64-bit. > > From where I'm standing, it looks that the pain of changing the > Alpha is more like a short painful sting, compared to the long > and nagging itch of not changing time_t. I'd rather have the > sting... > > Just FYI, Alpha will be dead long before 2038. It's not really a widely used embedded target, so I don't think there will be legacy Alpha systems running by then. In short, there is very little gain for the pain here. Just leave it alone. :) Another interesting question is what do we do with ppc. It is ILP32, but it's a new arch, so we could make time_t 64-bit on it (except that then time_t > long which could be a problem.) -- 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 31 3:24:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 6840137B401 for ; Wed, 31 Oct 2001 03:24:42 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15ytU8-0001Ed-0Y; Wed, 31 Oct 2001 11:24:40 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9VBNO789659; Wed, 31 Oct 2001 11:23:24 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 31 Oct 2001 11:23:24 +0000 (GMT) From: Doug Rabson To: Marcel Moolenaar Cc: Subject: Re: FYI: A thought on 64-bit time_t on Alpha In-Reply-To: <20011030225720.A39348@dhcp01.pn.xcllnt.net> 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 Tue, 30 Oct 2001, Marcel Moolenaar wrote: > Gang, > > We all seem to be of the opinion that the 64-bit archs should > have a 64-bit time_t. The question that is unanswered at this > time is whether this includes the Alpha. > > What I want to avoid is that Alpha will continue to be the odd > one even if it's not anymore the only 64-bit arch (or even the > only "other" arch). For some reason I don't think it's a good > idea to have the Alpha cuddle up with i386. Not only will it > be the odd one among the 64-bit archs, it will not stop being > the odd one in the 32-bit camp. > > So, whatever we decide, let's keep in mind that it can harm the > Alpha too if we treat it as an 32-bit arch and not have time_t > be 64-bit. > > From where I'm standing, it looks that the pain of changing the > Alpha is more like a short painful sting, compared to the long > and nagging itch of not changing time_t. I'd rather have the > sting... > > Just FYI, Moving alpha to use 64bit time_t would be hard. We still need to preserve compatiblity with older systems which means rolling new syscalls for all time related calls and compat shims for the old calls. It would be exactly the same amount of work needed to move i386. The main difference with ia64, sparc64 and ppc is that there is no old code to be compatible with so we don't have to bump the syscalls. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 4:40:10 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 5BDBE37B406 for ; Wed, 31 Oct 2001 04:39:47 -0800 (PST) Received: (qmail 61478 invoked by uid 1000); 31 Oct 2001 11:22:47 -0000 Date: Wed, 31 Oct 2001 13:22:47 +0200 From: Peter Pentchev To: arch@FreeBSD.org Cc: audit@FreeBSD.org Subject: Re: sysctl(8) enhancement: display sysctl MIB's Message-ID: <20011031132247.B13366@straylight.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, audit@FreeBSD.org References: <20010723004034.I882@ringworld.oblivion.bg> <20010723104201.855893E2F@bazooka.unixfreak.org> <20010723140620.A52175@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010723140620.A52175@ringworld.oblivion.bg>; from roam@orbitel.bg on Mon, Jul 23, 2001 at 02:06:20PM +0300 Sender: owner-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, Here's the patch to the updated sysctl sources after Anton Berezin added the '-e' option. For those who have missed the previous discussion, this patch adds a new '-m' option which displays the MIB's before the sysctl names. E.g. [roam@straylight:v4 ~/fbsd/r/src/sbin/sysctl]$ ./sysctl net.local net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.maxdgram: 2048 net.local.dgram.recvspace: 4096 net.local.inflight: 0 [roam@straylight:v4 ~/fbsd/r/src/sbin/sysctl]$ ./sysctl -m net.local 4.1.1.155 net.local.stream.sendspace: 8192 4.1.1.156 net.local.stream.recvspace: 8192 4.1.2.157 net.local.dgram.maxdgram: 2048 4.1.2.158 net.local.dgram.recvspace: 4096 4.1.159 net.local.inflight: 0 [roam@straylight:v4 ~/fbsd/r/src/sbin/sysctl]$ G'luck, Peter -- What would this sentence be like if pi were 3? Index: src/sbin/sysctl/sysctl.8 =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.8,v retrieving revision 1.39 diff -u -r1.39 sysctl.8 --- src/sbin/sysctl/sysctl.8 30 Oct 2001 20:15:32 -0000 1.39 +++ src/sbin/sysctl/sysctl.8 31 Oct 2001 09:40:46 -0000 @@ -40,11 +40,11 @@ .Nd get or set kernel state .Sh SYNOPSIS .Nm -.Op Fl beNnox +.Op Fl bemNnox .Ar name Ns Op = Ns Ar value .Ar ... .Nm -.Op Fl beNnox +.Op Fl bemNnox .Fl a .Sh DESCRIPTION The @@ -81,6 +81,11 @@ or .Fl n is specified, or a variable is being set. +.It Fl m +Specify that the MIB numerical value should be printed before the name. +This option is ignored if +.Fl n +is specified. .It Fl N Show only variable names, not their values. This is particularly useful with shells that offer programmable Index: src/sbin/sysctl/sysctl.c =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.38 diff -u -r1.38 sysctl.c --- src/sbin/sysctl/sysctl.c 30 Oct 2001 20:15:32 -0000 1.38 +++ src/sbin/sysctl/sysctl.c 31 Oct 2001 09:51:47 -0000 @@ -58,10 +58,11 @@ #include #include -static int aflag, bflag, eflag, Nflag, nflag, oflag, xflag; +static int aflag, bflag, eflag, mflag, Nflag, nflag, oflag, xflag; static int oidfmt(int *, int, char *, u_int *); static void parse(char *); +static int show_varname(const char *, const int *, int); static int show_var(int *, int); static int sysctl_all (int *oid, int len); static int name2oid(char *, int *); @@ -71,8 +72,8 @@ { (void)fprintf(stderr, "%s\n%s\n", - "usage: sysctl [-beNnox] variable[=value] ...", - " sysctl [-beNnox] -a"); + "usage: sysctl [-bemNnox] variable[=value] ...", + " sysctl [-bemNnox] -a"); exit(1); } @@ -83,7 +84,7 @@ setbuf(stdout,0); setbuf(stderr,0); - while ((ch = getopt(argc, argv, "AabeNnowxX")) != -1) { + while ((ch = getopt(argc, argv, "AabemNnowxX")) != -1) { switch (ch) { case 'A': /* compatibility */ @@ -98,6 +99,9 @@ case 'e': eflag = 1; break; + case 'm': + mflag = 1; + break; case 'N': Nflag = 1; break; @@ -372,6 +376,29 @@ } /* + * This formats and outputs the name of one variable. + * If the -m command-line flag was specified, the MIB value + * is also output. + */ + +static int +show_varname(const char *name, const int *oid, int len) +{ + int i; + + if (nflag) + return; + + if (mflag) { + for (i = 0; i < len - 1; i++) + printf("%X.", oid[i]); + printf("%X ", oid[i]); + } + + printf("%s%s", name, eflag? "=": ": "); +} + +/* * This formats and outputs the value of one variable * * Returns zero if anything was actually output. @@ -383,7 +410,7 @@ show_var(int *oid, int nlen) { u_char buf[BUFSIZ], *val, *p; - char name[BUFSIZ], *fmt, *sep; + char name[BUFSIZ], *fmt; int qoid[CTL_MAXNAME+2]; int i; size_t j, len; @@ -400,15 +427,10 @@ err(1, "sysctl name %d %d %d", i, j, errno); if (Nflag) { - printf("%s", name); + show_varname(name, oid, nlen); return (0); } - if (eflag) - sep = "="; - else - sep = ": "; - /* find an estimate of how much we need for this var */ j = 0; i = sysctl(oid, nlen, 0, &j, 0, 0); @@ -438,14 +460,12 @@ p = val; switch (*fmt) { case 'A': - if (!nflag) - printf("%s%s", name, sep); + show_varname(name, oid, nlen); printf("%s", p); return (0); case 'I': - if (!nflag) - printf("%s%s", name, sep); + show_varname(name, oid, nlen); fmt++; val = ""; while (len >= sizeof(int)) { @@ -460,8 +480,7 @@ return (0); case 'L': - if (!nflag) - printf("%s%s", name, sep); + show_varname(name, oid, nlen); fmt++; val = ""; while (len >= sizeof(long)) { @@ -476,8 +495,7 @@ return (0); case 'P': - if (!nflag) - printf("%s%s", name, sep); + show_varname(name, oid, nlen); printf("%p", *(void **)p); return (0); @@ -495,16 +513,14 @@ else func = NULL; if (func) { - if (!nflag) - printf("%s%s", name, sep); + show_varname(name, oid, nlen); return ((*func)(len, p)); } /* FALL THROUGH */ default: if (!oflag && !xflag) return (1); - if (!nflag) - printf("%s%s", name, sep); + show_varname(name, oid, nlen); printf("Format:%s Length:%d Dump:0x", fmt, len); while (len-- && (xflag || p < val + 16)) printf("%02x", *p++); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 7:29:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id A9E2037B401; Wed, 31 Oct 2001 07:29:53 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id f9VFTVY44934; Wed, 31 Oct 2001 10:29:33 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200110311529.f9VFTVY44934@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Peter Pentchev Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: sysctl(8) enhancement: display sysctl MIB's References: <20010723004034.I882@ringworld.oblivion.bg> <20010723104201.855893E2F@bazooka.unixfreak.org> <20010723140620.A52175@ringworld.oblivion.bg> <20011031132247.B13366@straylight.oblivion.bg> In-reply-to: Your message of "Wed, 31 Oct 2001 13:22:47 +0200." <20011031132247.B13366@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Oct 2001 10:29:31 -0500 Sender: owner-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 value desiplayed is typically called the OID (object id). The MIB (Management Information Base) is the whole collection of all the objects, enumerated with OID's. You might want to update the documentation to clarify this. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 11: 5:37 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 2F57537B403 for ; Wed, 31 Oct 2001 11:05:35 -0800 (PST) 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 f9VJ5UQ23756; Wed, 31 Oct 2001 14:05:30 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011030225720.A39348@dhcp01.pn.xcllnt.net> References: <20011030225720.A39348@dhcp01.pn.xcllnt.net> Date: Wed, 31 Oct 2001 14:05:28 -0500 To: Marcel Moolenaar , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: FYI: A thought on 64-bit time_t on Alpha 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:57 PM -0800 10/30/01, Marcel Moolenaar wrote: >We all seem to be of the opinion that the 64-bit archs should >have a 64-bit time_t. The question that is unanswered at this >time is whether this includes the Alpha. > >What I want to avoid is that Alpha will continue to be the odd >one even if it's not anymore the only 64-bit arch (or even the >only "other" arch). I think this is an issue for the main alpha users to decide, but I would note that there are two ways to think of it. One is *whether* alpha time_t should be 64-bit, and the second is *when* it should go to 64-bit. I think all the new platforms (sparc64 and ia-64, at least) should be 64-bit time_t's for 5.0-release. For alpha users, it might be less painful if alpha remained 32-bit for 5.0-release, and then consider making time_t 64-bit for 6.0-release. That way, Alpha users can feel more comfortable that the most of the 64-bit issues will have been addressed. -- 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 31 11:47:55 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 314AC37B405 for ; Wed, 31 Oct 2001 11:47:48 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by devonshire.cnchost.com id OAA05182; Wed, 31 Oct 2001 14:47:28 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110311947.OAA05182@devonshire.cnchost.com> To: Peter Jeremy Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Wed, 31 Oct 2001 16:37:41 +1100." <20011031163741.C85128@gsmx07.alcatel.com.au> Date: Wed, 31 Oct 2001 11:47:28 -0800 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. > > Are you sure? I've just _measured_ it on a PIII-600 and came up with > 211nsec (averaged over 1e7 loops). Keep in mind that this solution > has to also work in embedded applications - which are several orders > of magnitude slower than this. Dang! My number is bogus:-( The best number I get is about 130ns on a 533Mhz PIII. Test source code included below. I am not sure what the bug was in the original code.... But the point remains that this is not a math nighmare or all that expensive even on a slow machine. BTW, strtoll or strtoq don't seem to work for reading long long numbers! > There are two logical timestamp formats for a binary computer: s/logical/convenient/. > 1) Fixed point seconds with M bits to the left of the binary > point and N bits to the right. > 2) Integral number of (fractional second units). (As used on > the IBM System 360 and later). My vote is for 2), where the fractional unit is 10^-9 seconds and I called it `nstime64_t'. I don't like fixed point. You may as well use floating point like long double since most processors these days have very good floating point performance but then it won't make the embedded system folks happy. There have been over 100 messages on this subject in the past few days and rather than respond to individual messages I will summarize my (evolved) view below one more time! Please prefix IMHO to every point! - converting to 64 bit time_t in a piecemeal fashion is not worth it at this point. - The sky is not to falling down until 2038! - Let us use some of that time in coming up with a compromise that works across the board as this problem afflicts almost *all* variants of Unix, including the ones on 64 bit platform. - The issue is *what* that compromise will be and that requires thinking through the implications of changes (as opposed to having some free time to code up a solution). - I am certainly not suggesting waiting till the last moment or even years to fix the problem. - time_t doesn't have to be closely tied to a processor's native integer type -- it just has to be some arithmetic type so arguments about 64 bit time_t on a 64 bit platform (and by implication, 256 bit time_t on 256 bit platform) are weak. - I am advocating a 64 bit type with a nanosecond resolution and 584 years of span as a reasonable compromise type: - a 64 bit time_t with a second resolution is an overkill; it is way more than the expected life of universe! - very few applications require resolution less than 1ns. - 584 years is a long enough time -- we can not even imagine what computers will be like in 100 years. BTW, a signed representation will cut this in half to 292 years, which is still good enough. Note this is just a proposal and I have not thought through all of its implications (for example, on struct tm). It may be that we need a more radical solution such a 128 bit type as PHK & other advocate or a long double or something. - Just moving to a second resolution 64 bit time_t will mean there will be a lot of inertia against doing anything better. - Dealing with standards bodies is a pain but we do heed standards in FreeBSD and sooner or later POSIX will have to face this issue at which point if FreeBSD solution is different we will end up having to replicate a bunch of things. [It may be that POSIX won't be able to agree on anything more that 64 bit time_t but I am not so pessimistic!] - I am comfortable with a parallel set of system/library calls for any new time type if that means old programs don't have to recompiled to read, e.g. old dump tapes or create them for old machines. - The issue of what the kernel uses internally is separate. As long as the kernel's representation can be mapped to time_t (or its descendent) we are fine. - what a filesystem uses for timestamping files is related but I do not see how UFS1 can be made to stretch beyond 2038. As for UFS2 or some other fs, a sufficiently general time type may remove the need for timeval or timespec and there needs to be mapping between a file timestamp and time_t (at least for the limited life of a computer) but why constrain them any more? - It is true that frivolous topics like C style cause long drawn-out arguments but the converse is not true; this is not a `bikeshed' issue. Once again, all in my humble opinion! -- bakul #include #include long long f(long long x, long long y); long long g(long long x, long long y); int main(int argc, char**argv) { long long x = strtoll(a[1], 0, 10); long long y = strtoll(a[2], 0, 10); long long z; unsigned long count = strtoul(a[3], 0, 0); int i; struct timeval t0, t1, t2; double d0, d1, d2; /* make x bigger since we can't read > 32 bit numbers with strtoll */ x *= x; printf("x=%lld, y=%lld, count=%ld\n", x, y, count); gettimeofday(&t0, 0); for (i = 0; i < count; i++) z = f(x, y); gettimeofday(&t1, 0); /* t1 - t0 == overhead time */ for (i = 0; i < count; i++) z = g(x, y); gettimeofday(&t2, 0); /* t2 - t1 == overhead + count divides time */ d0 = t0.tv_sec*1E9 + t0.tv_usec*1E3; d1 = t1.tv_sec*1E9 + t1.tv_usec*1E3; d2 = t2.tv_sec*1E9 + t2.tv_usec*1E3; printf("%g\n", (d2-d1-(d1-d0))/count); exit(0); } long long f(long long x, long long y) { return x; } long long g(long long x, long long y) { return x / y; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 12:20:17 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 06F7137B403 for ; Wed, 31 Oct 2001 12:20:12 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9VKIt975870; Wed, 31 Oct 2001 21:18:55 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bakul Shah Cc: Peter Jeremy , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Wed, 31 Oct 2001 11:47:28 PST." <200110311947.OAA05182@devonshire.cnchost.com> Date: Wed, 31 Oct 2001 21:18:55 +0100 Message-ID: <75868.1004559535@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 <200110311947.OAA05182@devonshire.cnchost.com>, Bakul Shah writes: >> 1) Fixed point seconds with M bits to the left of the binary >> point and N bits to the right. >> 2) Integral number of (fractional second units). (As used on >> the IBM System 360 and later). > >My vote is for 2), where the fractional unit is 10^-9 seconds >and I called it `nstime64_t'. I don't like fixed point. You >may as well use floating point like long double since most >processors these days have very good floating point >performance but then it won't make the embedded system folks >happy. Using double in the kernel is not needed. 10^-9 is not enough internal resolution for an NTP compliant timekeeping implementation. We currently use 10E-9/2^32. There is _no_ benefit to use a metric unit internally in the kernel, in fact, there is only extra overhead whenever you add together or subtract two timestamps, (which we do everytime we (re)schedule a task on a cpu). > - very few applications require resolution less than 1ns. ... yet. (Submitted to "Famous last words" for consideration). There are a number of considerations, which build on each other. Lets tackle them bottom up: Timecounter implementation: Needs to be able to tell 1433 MHz from 1500 MHz. This is the difference between .6666 nsec and .692856... nsec. Currently the format used is a 96 bit format: 32bit seconds 32bit nanoseconds 32bit fraction of nanoseconds A lot of special casing code can go away if this becomes a simple binary format instead. Since computers of relevance are 32bit or 64bit the logical widths are 64 (not enough), 96(not enough for enough time) or 128 (enough!). Kernel consumers of time: Here we have the primary need of the process statistics which need to figure out how long time each process sat on the CPU, and the devinfo stuff which calculates device statistics. These two together are the overwhelming users of timestamps in the kernel. They both need to find delta-T's. They get a timestamp, wait some time, get another one, subtract them. For this the timespec/timeval mess sux. We can argue what resolution we need for this, but I think that with 2GHz CPU's announced, 1 nanosecond is not enough for very long time. We want to be able to account (and profile!) down to the cpu-clock. 32bit fractions of second gives us 4.mumble GHz, that is not enough for long enough. In other words, we need a fraction of seconds with more than 32 bits. More than 32bits is 64 bits. 53 bits is simply not a good idea on 32 or 64 bit computers... Userland consumers: Generally want timeval or timespec because of various standards brain-damage. So, where does that leave us ? 1. nanoseconds are not enough. 2. We have to use 64bit fractions of seconds unless we want to shift all the time. 3. An internal 64.64 fixed point binary format can be converted to practically any other timeformat and is cheaper to convert and do arithmetic on than any other format. 4. For a couple of years we can make do with a 64bit (32.32) format for process accounting if we want to, but long term it will not hold up. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 12:34:58 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 AE9C737B405 for ; Wed, 31 Oct 2001 12:34:51 -0800 (PST) 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 HAA01941; Thu, 1 Nov 2001 07:34:44 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01KA6K16NEQ8VLLLIS@cim.alcatel.com.au>; Thu, 1 Nov 2001 07:34:42 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9VKYfV94703; Thu, 01 Nov 2001 07:34:41 +1100 Content-return: prohibited Date: Thu, 01 Nov 2001 07:34:41 +1100 From: Peter Jeremy Subject: Re: 64 bit times revisited.. In-reply-to: <3BD9950D.BB72A8F9@mindspring.com>; from tlambert2@mindspring.com on Fri, Oct 26, 2001 at 09:53:33AM -0700 To: Terry Lambert Cc: arch@FreeBSD.ORG Mail-Followup-To: Terry Lambert , arch@FreeBSD.ORG Message-id: <20011101073441.A94653@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Resend due to bounce] [Cc: trimmed as per followup list] On 2001-Oct-26 09:53:33 -0700, Terry Lambert wrote: >You can alternately resolve this problem by forcing the >timestamp to be monotonically increasing, FWIW. Note that AmigaOS did this (see timer.device TR_GETSYSTIME). I think this is a good idea in general. It's trivial on a UP system. It's not too difficult on an SMP system. BUT I have no idea how to efficiently implement it on a cluster - which is where I suspect computing is moving. There are two requirements: Firstly, the resolution of the timestamp must be finer that the typical delay between gettimeofday() (or equivalent) calls. Secondly the required precision of the timestamps (as a time) must be less than the available resolution (since the low few bits may be noise). >This could be done in the FS, without any ugly hacks... Also agreed. In fact, I'd like to split this discussion into two bikesheds - one to discuss time_t, struct timeval et al, and another one to discuss timestamps on disks - there is no reason for the two formats to be the same - nothing in userland (other than dump/restore - which is a special case) needs know the UFS timestamp format. We just need to be able to translate between the two formats reasonably efficiently. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 12:54:33 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 81C9137B401 for ; Wed, 31 Oct 2001 12:54:21 -0800 (PST) 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 HAA03698; Thu, 1 Nov 2001 07:53:51 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01KA6KOPBHWWVFIYV8@cim.alcatel.com.au>; Thu, 1 Nov 2001 07:53:40 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9VKrlp94849; Thu, 01 Nov 2001 07:53:47 +1100 Content-return: prohibited Date: Thu, 01 Nov 2001 07:53:47 +1100 From: Peter Jeremy Subject: Re: 64 bit times revisited.. In-reply-to: <200110261914.PAA17908@devonshire.cnchost.com>; from bakul@bitblocks.com on Fri, Oct 26, 2001 at 12:15:00PM -0700 To: Bakul Shah Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Mail-Followup-To: Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Message-id: <20011101075347.A94706@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Resend due to mail bouncing] On 2001-Oct-26 12:15:00 -0700, Bakul Shah wrote: >> >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. Are you sure? I've just _measured_ it on a PIII-600 and came up with 211nsec (averaged over 1e7 loops). Keep in mind that this solution has to also work in embedded applications - which are several orders of magnitude slower than this. >> here: resolution 1/2^64 second. >> >> Decimal computers lost the race and they ai2768n't coming back. We want >> arithmetic on binary computers to be fast and simple. > >Most everyone uses powers of ten for timing units. No-one is suggesting that I/O has to be in binary. There's no reason why you can't convert the internal binary format into decimal. EDSAC managed this more than 50 years ago. Note that it's _easier_ to convert a binary fraction to an arbitrary number of decimal places than converting a integral number of zotto (or whatever) seconds to decimal (feel free to consult [1] if you disagree). There are two logical timestamp formats for a binary computer: 1) Fixed point seconds with M bits to the left of the binary point and N bits to the right. 2) Integral number of (fractional second units). (As used on the IBM System 360 and later). Both of which are far better than having programs full of t1.tv_sec -= t2.tv_sec; if ((t1.tv_usec -= t2.tv_usec) < 0) { t1.tv_usec += 1000000; t1.tv_sec--; } The former is probably a better choice because it's easier to expand to the right (as things speed up) and you can more cheaply extract lower-precision variants. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 13: 5:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by hub.freebsd.org (Postfix) with ESMTP id 48F9B37B406 for ; Wed, 31 Oct 2001 13:05:16 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by wellington.cnchost.com id QAA16756; Wed, 31 Oct 2001 16:04:57 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110312104.QAA16756@wellington.cnchost.com> To: Poul-Henning Kamp Cc: Peter Jeremy , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Wed, 31 Oct 2001 21:18:55 +0100." <75868.1004559535@critter.freebsd.dk> Date: Wed, 31 Oct 2001 13:04:55 -0800 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 > Using double in the kernel is not needed. Not needed because...? Actually double arithmetic is even faster! 45ns for divide on the same machine where I get 130ns for long long divide. In the program I posted change all long long to double and fix up io conversion. Changing it to long double yields 62ns; still faster than long long. I bet your 128 bit fixed point will be much worse. > 10^-9 is not enough internal resolution for an NTP compliant > timekeeping implementation. We currently use 10E-9/2^32. Which your average machine isn't. PCs and even suns or sgis and whatnot have crystals with lousy staibility as you well know. > There is _no_ benefit to use a metric unit internally in > the kernel, in fact, there is only extra overhead whenever > you add together or subtract two timestamps, (which we do > everytime we (re)schedule a task on a cpu). Well you don't keep a pair like in timeval or timespec. It is a long long where the unit of count is 1 ns so there is no extra overhead (but you are better off using a long double!). Also, shouldn't you be using time relative to boot time for scheduling? > > - very few applications require resolution less than 1ns. > ... yet. (Submitted to "Famous last words" for consideration). This is not the same case as having insufficient number of bits in an address or 640Kbytes being good enough. I am sure there will be more and more applications the % won't increase. 128 bit is enough but not necessary for most userland apps. > Here we have the primary need of the process statistics > which need to figure out how long time each process sat > on the CPU, and the devinfo stuff which calculates device > statistics. These two together are the overwhelming > users of timestamps in the kernel. This should be using bootime specific time type, which doesn't need multi century range but finer resolution. > They both need to find delta-T's. They get a timestamp, > wait some time, get another one, subtract them. For this > the timespec/timeval mess sux. Agreed. > We can argue what resolution we need for this, but I think > that with 2GHz CPU's announced, 1 nanosecond is not enough > for very long time. We want to be able to account (and > profile!) down to the cpu-clock. 32bit fractions of second > gives us 4.mumble GHz, that is not enough for long enough. I have no problem in using a finer clock here; I just don't think it should be the same as a generic time type. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 13:41:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.250.130.228]) by hub.freebsd.org (Postfix) with ESMTP id AA8A637B405 for ; Wed, 31 Oct 2001 13:41:54 -0800 (PST) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.3) with ESMTP id f9VLf4d38200; Wed, 31 Oct 2001 13:41:04 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Wed, 31 Oct 2001 13:41:02 -0800 (PST) From: Kelly Yancey To: Bakul Shah Cc: Poul-Henning Kamp , Peter Jeremy , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <200110312104.QAA16756@wellington.cnchost.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 Wed, 31 Oct 2001, Bakul Shah wrote: > > Using double in the kernel is not needed. > > Not needed because...? > > Actually double arithmetic is even faster! 45ns for divide on > the same machine where I get 130ns for long long divide. In > the program I posted change all long long to double and fix > up io conversion. Changing it to long double yields 62ns; > still faster than long long. I bet your 128 bit fixed point > will be much worse. > Yes, but to use floating-point in the kernel would require architectures like the x86 to save the fp state on every context switch[*]. If my memory serves me, FNSAVE on the x86 takes a heck of a lot longer than 130ns for all current processor models. Kelly [*] Actually, you wouldn't have to save fp state on every context switch, instead you could just set the CR0.TS bit on entry to the kernel, so that if the kernel were to use fp registers, a DNA exception would be thrown allowing the fp state to be saved. If I read i386/support.s right, this is not implemented and it is doubtful it would be worth implementing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 13:48:16 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 722B637B403 for ; Wed, 31 Oct 2001 13:48:11 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9VLl8977751; Wed, 31 Oct 2001 22:47:08 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bakul Shah Cc: Peter Jeremy , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Wed, 31 Oct 2001 13:04:55 PST." <200110312104.QAA16756@wellington.cnchost.com> Date: Wed, 31 Oct 2001 22:47:08 +0100 Message-ID: <77749.1004564828@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 <200110312104.QAA16756@wellington.cnchost.com>, Bakul Shah writes: >> Using double in the kernel is not needed. > >Not needed because...? The needed precision is reachable in integer fixed point, and we don't currently waste time saving FPU state in context switches. >> 10^-9 is not enough internal resolution for an NTP compliant >> timekeeping implementation. We currently use 10E-9/2^32. > >Which your average machine isn't. PCs and even suns or sgis >and whatnot have crystals with lousy staibility as you well >know. Right, but you need to be able to faithfully implement your half of the NTP PLL without systematics or rounding errors. nanosecond resolution alone will not do that and leads to box-car effects in the PLL. >> There is _no_ benefit to use a metric unit internally in >> the kernel, in fact, there is only extra overhead whenever >> you add together or subtract two timestamps, (which we do >> everytime we (re)schedule a task on a cpu). > >Well you don't keep a pair like in timeval or timespec. It >is a long long where the unit of count is 1 ns so there is no >extra overhead (but you are better off using a long double!). >Also, shouldn't you be using time relative to boot time for >scheduling? 1. There is extra overhead if your basic representation isn't binary: you need to divide instead of shift to get seconds. 2. We already use time relative to boot for accounting. >128 bit is enough but not necessary for most userland apps. for the current interpretation of quantum mechanics, 64 bits fractions on seconds are decisively enough. >> Here we have the primary need of the process statistics >> which need to figure out how long time each process sat >> on the CPU, and the devinfo stuff which calculates device >> statistics. These two together are the overwhelming >> users of timestamps in the kernel. > >This should be using bootime specific time type, which >doesn't need multi century range but finer resolution. Would you mind examining current reality before you pontificate ? Thankyou. >> We can argue what resolution we need for this, but I think >> that with 2GHz CPU's announced, 1 nanosecond is not enough >> for very long time. We want to be able to account (and >> profile!) down to the cpu-clock. 32bit fractions of second >> gives us 4.mumble GHz, that is not enough for long enough. > >I have no problem in using a finer clock here; I just don't think it >should be the same as a generic time type. But you don't seem to realize that a fixed point binary format is the only format which can be converted to any other format cheaply and efficiently. -- 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 Wed Oct 31 13:56:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id 159E537B406; Wed, 31 Oct 2001 13:56:13 -0800 (PST) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id B92CB1D146; Wed, 31 Oct 2001 21:56:10 +0000 (GMT) Date: Wed, 31 Oct 2001 21:56:10 -0000 From: Paul Richards To: Lyndon Nerenberg , Giorgos Keramidas Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks Message-ID: <763630000.1004565370@lobster.originative.co.uk> In-Reply-To: <200110301650.f9UGof0H009849@atg.aciworldwide.com> References: <200110301650.f9UGof0H009849@atg.aciworldwide.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-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 Tuesday, October 30, 2001 09:50:41 -0700 Lyndon Nerenberg wrote: >> Well, Lyndon, this is quickly turning into a flamefest. > > 64 bit time_t is a flamefest. This, OTOH, is a very reasonable > discussion. > >> It really is not worth it, is it? > > Without discussion there would never be change. I was curious to > discover the rational for keeping the GNU names for the C compiler > (but not the other GNU tools). I'm not sure I really received an > answer, and maybe that's the answer in itself. When I originally imported gcc2, for the very first FreeBSD release, I actually patched it so that it looked like it was cc. Somewhere along the way this practice stopped for cc but not the other tools. It had the benefit in that we could support development versions of gcc that were installed in /usr/local (ports hadn't been invented then). We could test newer compilers quite easily that way by just changing CC to be gcc instead of cc. Likewise, which was an issue at the time with the move to 2.x versions of gcc, other software that required a newer version of the compiler could be built using gcc rather than the system's cc. I'm not sure who stopped that practice but it was useful. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 15:20:54 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 B414E37B406 for ; Wed, 31 Oct 2001 15:20:40 -0800 (PST) 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 KAA20998; Thu, 1 Nov 2001 10:20:18 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01KA6PSAV234VFJ0IC@cim.alcatel.com.au>; Thu, 1 Nov 2001 10:20:08 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9VNKEk95913; Thu, 01 Nov 2001 10:20:14 +1100 Content-return: prohibited Date: Thu, 01 Nov 2001 10:20:14 +1100 From: Peter Jeremy Subject: Re: 64 bit times revisited.. In-reply-to: <200110311947.OAA05182@devonshire.cnchost.com>; from bakul@bitblocks.com on Wed, Oct 31, 2001 at 11:47:28AM -0800 To: Bakul Shah Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Mail-Followup-To: Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Message-id: <20011101102014.D94635@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: <20011031163741.C85128@gsmx07.alcatel.com.au> <200110311947.OAA05182@devonshire.cnchost.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 2001-Oct-31 11:47:28 -0800, Bakul Shah wrote: >> >On my 500Mhz PIII it takes about 4.6ns to divide a 64 bit >> >number by a 64 bit 10^9. ... >Dang! My number is bogus:-( The best number I get is about >130ns on a 533Mhz PIII. Your best number is not particularly relevant. As you've noticed, the timing is data-dependent, so you need to average the time over random data (I was using 100 random 64-bit numbers courtesy of random(3)). Your average time is probably closer to my 211nsec. (Also, I included negative quotients - which your program doesn't allow and which I suspect are slower). There are problems with any approach that involves division: 1) Division is _slow_. It's much harder to build a fast divider than a fast multiplier and dividers don't scale to higher precisions. 2) Some architectures don't have hardware integer division at all. Alpha is one. I'm not sure about IA-64 or Sparc64. 3) The solution has to work _today_ on embedded processors. My guess is that a 486 is around 2 orders of magnitude slower than a PIII. >> 1) Fixed point seconds with M bits to the left of the binary >> point and N bits to the right. >> 2) Integral number of (fractional second units). (As used on >> the IBM System 360 and later). > >My vote is for 2), where the fractional unit is 10^-9 seconds >and I called it `nstime64_t'. The problem with fractional units is extending them when you run out of resolution and/or precision. Either you extend them as a binary fraction (from memory, the S/360 uses a 64-bit TOD which counts in units of 2^-12 usec), or you switch to a smaller decimal unit. The former means you no longer have a clean metric fraction. The latter makes it very painful to convert between the "old" and "new" formats. nsec resolution is inadequate _today_ for things like NTP PLL's. It's even inadequate for today's CPU speeds. Converting your nstime64_t to struct timespec needs an expensive 64-bit division returning both quotient and remainder (the Alpha has tricks to manage reasonably fast division by a constant, but you don't get a remainder). Converting it to a struct timeval needs a further 32-bit division. OTOH, a fixed-point binary scheme makes it easy to extract the seconds - at worst a shift to align the binary point to a word boundary. Converting to either struct timeval or struct timespec needs a single, unsigned, widening multiply. And I don't think there's even any need for using all 64 fraction bits - the error in using a 32x32->64 multiply averages out to ~0.25nsec. This can be done efficiently even on a 386. >- converting to 64 bit time_t in a piecemeal fashion is not > worth it at this point. > - The sky is not to falling down until 2038! Y2K should have taught us that software winds up being used for far longer than was originally intended - and one of the major costs was finding this software. 2038 is biting some applications now - and the number will only rise with time. The quicker we solve the problem, the less re-work that will be necessary. >- I am advocating a 64 bit type with a nanosecond resolution > and 584 years of span as a reasonable compromise type: nsec resolution is inadequate today. It'll be a joke in 10 years, let alone by 2038. IMHO, it makes sense for a timestamp to be (1< Note this is just a proposal and I have not thought through > all of its implications (for example, on struct tm). It > may be that we need a more radical solution such a 128 bit > type as PHK & other advocate or a long double or something. I quite like PHK's 64.64 proposal. >- The issue of what the kernel uses internally is separate. > As long as the kernel's representation can be mapped to > time_t (or its descendent) we are fine. Agreed. And a binary kernel timestamp is the simplest way to achieve this. >- what a filesystem uses for timestamping files is related Agreed, but this is a different bikeshed - on-disk timestamps do not need to be the same as either kernel or userland timestamps. The requirements for both range and resolution are not necessarily the same, and the resolution requirements may differ for the 3 different inode timestamps. The only real relationship between the on-disk timestamps and kernel/userland timestamps is that the kernel can effeciently convert between them. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 16: 2:49 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 626CC37B405 for ; Wed, 31 Oct 2001 16:02:47 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fA102UC18044; Wed, 31 Oct 2001 19:02:30 -0500 (EST) (envelope-from wollman) Date: Wed, 31 Oct 2001 19:02:30 -0500 (EST) From: Garrett Wollman Message-Id: <200111010002.fA102UC18044@khavrinen.lcs.mit.edu> To: peter.jeremy@alcatel.com.au Subject: Re: 64 bit times revisited.. In-Reply-To: <20011101102014.D94635@gsmx07.alcatel.com.au> References: <20011031163741.C85128@gsmx07.alcatel.com.au> <200110311947.OAA05182@devonshire.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 <20011101102014.D94635@gsmx07.alcatel.com.au> you write: >finding this software. 2038 is biting some applications now Those applications are broken. Any application which deals with prospective events that far into the future needs to be dealing with dates, not POSIX seconds-since-the-epoch. There are many changes which can happen between now and 2038 which would make any calculation involving seconds-since-the-epoch even more invalid than it already is. If you have a real-world application that depends on something happening precisely 1,142,910,768 seconds from now, I'd like to hear about it. -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 31 18:27:14 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 013DE37B403 for ; Wed, 31 Oct 2001 18:27:12 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fA12R9L19982; Wed, 31 Oct 2001 18:27:09 -0800 (PST) (envelope-from obrien) Date: Wed, 31 Oct 2001 18:27:09 -0800 From: "David O'Brien" To: Gordon Tetlow Cc: arch@freebsd.org Subject: Re: rc.d patch to test out Message-ID: <20011031182709.C94270@dragon.nuxi.com> Reply-To: obrien@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 gordont@gnf.org on Tue, Oct 30, 2001 at 04:39:51PM -0800 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 30, 2001 at 04:39:51PM -0800, Gordon Tetlow wrote: > Since O'Brien ... *sigh* Is people's grammer gotten this bad in emails these days? Calling someone by their last name like that is rude and not proper English grammer. I do not know why everyone here seems to do this to me. Acceptable forms: Mr. O'Brien David O'Brien DEO (my initals, an accepted Unixism) obrien (my login, another accepted Unixism) David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 31 19:36:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from p3.locore.ca (p3.locore.ca [198.96.117.171]) by hub.freebsd.org (Postfix) with ESMTP id BAEE937B401 for ; Wed, 31 Oct 2001 19:36:27 -0800 (PST) Received: (from jake@localhost) by p3.locore.ca (8.11.4/8.11.4) id fA13Xlq52110; Wed, 31 Oct 2001 22:33:47 -0500 (EST) (envelope-from jake) Date: Wed, 31 Oct 2001 22:33:47 -0500 From: Jake Burkholder To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Makefile unification Message-ID: <20011031223347.B45913@locore.ca> References: <200110300442.f9U4gM701469@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110300442.f9U4gM701469@harmony.village.org>; from imp@harmony.village.org on Mon, Oct 29, 2001 at 09:42: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 Apparently, On Mon, Oct 29, 2001 at 09:42:22PM -0700, Warner Losh said words to the effect of; > > I took some time out to update my Makefiles and redo my kern.mk > patches that had gotten out of date before I could get them done. > These patches are up to date and appear to work for me on i386 (and > maybe pc98, it is building now): > > http://people.freebsd.org/~imp/Pkern > > It creates a new src/sys/conf/kern.mk that contains most of the guts > of the kernel makefiles to make it even easier to keep them all in > sync. > > Please let me know what you think and if I've broken anything, > especially for non x86 MACHINE_ARCH. > > Warner There are a couple problems in Makefile.sparc64: The first .include should be kern1.mk, not kern2.mk. The rule for exception.o needs to be after the include of kern2.mk or else "make" in the compile directory just builds exception.o instead of the whole kernel. I guess "make all" would work. -Wl,shared in HACK_EXTRA_FLAGS should be -Wl,-shared. btw, this is probably due to using a stock gcc cross compiler instead of the soon to be in tree tool chain; it doesn't DTRT for -shared apparently. I had to add FMT= (ie nothing) in Makefile.sparc64 so -elf isn't passed to the linker. This is also probably due to using a stock gcc; the linker takes -elf to be -e lf and tries to make "lf" be the entry point (which obviously doesn't exist). I've put the modified Makefile.sparc64 up here: http://people.freebsd.org/~jake/Makefile.sparc64 Other than that it seems to work fine. Thanks! Jake > > 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 Wed Oct 31 20: 1:19 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 D866137B401; Wed, 31 Oct 2001 20:01:15 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id VAA10898; Wed, 31 Oct 2001 21:01:10 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fA1418Z18056; Wed, 31 Oct 2001 21:01:08 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15328.51460.27299.496597@caddis.yogotech.com> Date: Wed, 31 Oct 2001 21:01:08 -0700 To: obrien@FreeBSD.ORG Cc: Gordon Tetlow , arch@FreeBSD.ORG Subject: Re: rc.d patch to test out In-Reply-To: <20011031182709.C94270@dragon.nuxi.com> References: <20011031182709.C94270@dragon.nuxi.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 > On Tue, Oct 30, 2001 at 04:39:51PM -0800, Gordon Tetlow wrote: > > Since O'Brien ... > > *sigh* Is people's grammer gotten this bad in emails these days? > > Calling someone by their last name like that is rude and not proper > English grammer. Not where I'm from. It's considered as normal as using someone's first name, and in other cultures using a first name is actually rude. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 0:34:58 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 936D637B405; Thu, 1 Nov 2001 00:34:56 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fA18Ykf43858; Thu, 1 Nov 2001 00:34:47 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: obrien@FreeBSD.ORG Cc: Gordon Tetlow , arch@FreeBSD.ORG Subject: Re: rc.d patch to test out In-Reply-To: Message from "David O'Brien" of "Wed, 31 Oct 2001 18:27:09 PST." <20011031182709.C94270@dragon.nuxi.com> Date: Thu, 01 Nov 2001 00:34:46 -0800 Message-ID: <43854.1004603686@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 > *sigh* Is people's grammer gotten this bad in emails these days? ^ Has You're mixing tenses otherwise. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 1: 8:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from 213.229.61.106.sh.interxion.inode.at (213.229.61.106.sh.interxion.inode.at [213.229.61.106]) by hub.freebsd.org (Postfix) with SMTP id 47B0037B403 for ; Thu, 1 Nov 2001 01:08:38 -0800 (PST) Received: from mta.excite.com(really [199.174.18.162]) by 213.229.61.106.sh.interxion.inode.at via smail with esmtp id for ; Thu, 1 Nov 2001 10:03:32 +0100 (CET) (Smail-3.2 1996-Jul-4 #1 built 2001-Jun-18) Message-ID: <00004ac42acb$00001bc5$00003a8a@mta.excite.com> To: From: noirequities1@excite.com Subject: Noir-Cygnus Announces An Investment Opportunity NJZHDKLJQXB Date: Sun, 02 Dec 2001 03:03:36 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: noirequities1@excite.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 Noir

Noir-Cygnus Equities

Specializing in Asset Based Securitizations=

October 30, 2001
Company Announces its Rule 504D Private Placement Offering

NOIR-CYGNUS EQUITIES, INC= . CFO, Lynden P. Bridges announced today that the company has releas= ed its Private Placement Offering for review and subscription by potentia= l investors. The Offering, under and pursuant to Rule 504(D) of the Securities Act, allows for any interested party to invest in the c= ompany=FFFFFF92s securities, subject to the terms of the statute. "The Company= has taken care to provide a fully qualified Offering Memorandum which = can only be accessed through the internet by first sending in a reques= t for a copy of the memorandum to the Company," stated Bridges.

The total amount of the Offering is $700,000 = divided into 2,800 Units composed of 1,000 shares of Class "B" C= ommon Stock. The stock is being sold at $0.25 cents per share. The minim= um purchase is for one (1) Unit ($250) and the maximum purchase allow= able is for four (4) Units ($1,000). A total of 2.8 Million Shares of C= lass "B" Stock are being offered. CEO, Harold Woods, Jr. note= d, "the purpose of this offering is to expand the shareholder ba= se of the Company. Noir-Cygnus has entered into negotiations to be acqui= red by a publicly-traded shell company. On conclusion of that acquisition= , and assuming the success of our business model, we will need 1,000 shareholders and the appropriate capital requirements in order to qualify for trading on the NASDAQ National Market System." Wo= ods noted that despite the mood of the country and marketplace, it was important to conduct this offering now in view of the de minimu= s interest rates that are being experienced in the financial markets representing an enormous business opportunity. "We must move = with all haste to execute not only on the business model, but to increa= se our shareholder base so that the Company=FFFFFF92s objectives will be = met without further delay."

To request a copy of the Company=FFFFFF92s Pr= ivate Placement Memorandum, go to the Company=FFFFFF92s website at www.n= oircygnusequities.com Click on "Investment Opportunities" and then click on "Investing In Noir-Cygnus Equities."

It should be noted that this announcement is not an offer to sell securities.  Offer and subscription can only be accomplished through the Private Placement Memorandum in those jurisdictions wh= ere such sale and purchase is permitted.

You are currently subscribed= to the Investors Holdings =FFFFFF99 Update.  You can change your ema= il preferences by clicking here and pressing, "send"  NOTE: By removing your email = address from our list you will no longer receive the FREE company Advisory or the FREE c= ompany Update.

 
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 1:11:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id D2E3437B405; Thu, 1 Nov 2001 01:11:24 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 15zDtj-000J90-00; Thu, 01 Nov 2001 11:12:27 +0200 From: Sheldon Hearn To: obrien@freebsd.org Cc: Gordon Tetlow , arch@freebsd.org Subject: Re: rc.d patch to test out In-reply-to: Your message of "Wed, 31 Oct 2001 18:27:09 PST." <20011031182709.C94270@dragon.nuxi.com> Date: Thu, 01 Nov 2001 11:12:27 +0200 Message-ID: <73593.1004605947@axl.seasidesoftware.co.za> Sender: owner-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, 31 Oct 2001 18:27:09 PST, "David O'Brien" wrote: > Calling someone by their last name like that is rude and not proper > English grammer. I do not know why everyone here seems to do this to me. That's probably true where you're from. It's not true everywhere. Keep in mind that this is an international effort. Also, remember that your freefall username is obrien, which is a clue a lot of people will use. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 7:52:46 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 9A2DF37B41D for ; Thu, 1 Nov 2001 07:52:33 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA06587; Thu, 1 Nov 2001 07:52:09 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda06585; Thu Nov 1 07:52:05 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id fA1FppR27583; Thu, 1 Nov 2001 07:51:51 -0800 (PST) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdH27566; Thu Nov 1 07:51:41 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id fA1FpVL05946; Thu, 1 Nov 2001 07:51:31 -0800 (PST) Message-Id: <200111011551.fA1FpVL05946@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdkp5940; Thu Nov 1 07:51:01 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: Peter Jeremy Cc: Bakul Shah , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Thu, 01 Nov 2001 10:20:14 +1100." <20011101102014.D94635@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Nov 2001 07:51:01 -0800 Sender: owner-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 <20011101102014.D94635@gsmx07.alcatel.com.au>, Peter Jeremy writes: > Y2K should have taught us that software winds up being used for far > longer than was originally intended - and one of the major costs was > finding this software. 2038 is biting some applications now - and the > number will only rise with time. The quicker we solve the problem, > the less re-work that will be necessary. The other thing that Y2K taught us is that sometimes you cannot find the source code, yet the binaries have been running for decades. I'm not advocating not going to 64 bit time_t but I think that cases where the source code has been lost should be considered, e.g. ELF branding for binaries built after 64 bit time_t has been implemented. However ultimately those binaries will break in 2038, so the question is, is this reasonable idea? 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 Thu Nov 1 9:54:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.gnf.org (relay.gnf.org [208.44.31.36]) by hub.freebsd.org (Postfix) with ESMTP id 8520137B406; Thu, 1 Nov 2001 09:54:47 -0800 (PST) Received: from mail.gnf.org (smtp.gnf.org [10.0.0.11]) by relay.gnf.org (8.11.6/8.11.6) with ESMTP id fA1Hsei29609; Thu, 1 Nov 2001 09:54:40 -0800 Received: by mail.gnf.org (Postfix, from userid 888) id 6574E11E50C; Thu, 1 Nov 2001 09:51:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id 58C2911A577; Thu, 1 Nov 2001 09:51:39 -0800 (PST) Date: Thu, 1 Nov 2001 09:51:37 -0800 (PST) From: Gordon Tetlow To: Sheldon Hearn Cc: , Subject: Re: rc.d patch to test out In-Reply-To: <73593.1004605947@axl.seasidesoftware.co.za> 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 Picking one at random... On Thu, 1 Nov 2001, Sheldon Hearn wrote: > On Wed, 31 Oct 2001 18:27:09 PST, "David O'Brien" wrote: > > > Calling someone by their last name like that is rude and not proper > > English grammer. I do not know why everyone here seems to do this to me. > > That's probably true where you're from. It's not true everywhere. Keep > in mind that this is an international effort. > > Also, remember that your freefall username is obrien, which is a clue a > lot of people will use. All of this aside, can I get some feedback on the actual patch? http://hobbes.melthusia.org/~gordont/rc_ng.diff Instructions are at the top of the patch. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 10: 2:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 890A937B401; Thu, 1 Nov 2001 10:02:40 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 15zMBh-000NZO-00; Thu, 01 Nov 2001 20:03:33 +0200 From: Sheldon Hearn To: Gordon Tetlow Cc: obrien@FreeBSD.ORG, arch@FreeBSD.ORG, dougb@FreeBSD.org Subject: Re: rc.d patch to test out In-reply-to: Your message of "Thu, 01 Nov 2001 09:51:37 PST." Date: Thu, 01 Nov 2001 20:03:33 +0200 Message-ID: <90605.1004637813@axl.seasidesoftware.co.za> Sender: owner-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, 01 Nov 2001 09:51:37 PST, Gordon Tetlow wrote: > All of this aside, can I get some feedback on the actual patch? > > http://hobbes.melthusia.org/~gordont/rc_ng.diff > > Instructions are at the top of the patch. I've been holding off on this because Doug Barton expressed a strong desire to drive the process. Since Doug has done considerable work in this area in the past, I felt it was worth giving him first stab. He's copied on this message. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 10:31:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from db-cvad-1-tmp.yahoo.com (db-cvad-1-tmp.yahoo.com [216.145.48.242]) by hub.freebsd.org (Postfix) with ESMTP id 6F54E37B403; Thu, 1 Nov 2001 10:31:41 -0800 (PST) Received: from DougBarton.net (master.gorean.org [10.0.0.2]) by db-cvad-1-tmp.yahoo.com (8.11.6/8.11.6) with ESMTP id fA1IV7w85906; Thu, 1 Nov 2001 10:31:08 -0800 (PST) (envelope-from DougB@DougBarton.net) Message-ID: <3BE194EB.5060303@DougBarton.net> Date: Thu, 01 Nov 2001 10:31:07 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Sheldon Hearn Cc: Gordon Tetlow , obrien@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: rc.d patch to test out References: <90605.1004637813@axl.seasidesoftware.co.za> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Sheldon Hearn wrote: > On Thu, 01 Nov 2001 09:51:37 PST, Gordon Tetlow wrote: > > >>All of this aside, can I get some feedback on the actual patch? >> >>http://hobbes.melthusia.org/~gordont/rc_ng.diff >> >>Instructions are at the top of the patch. >> > > I've been holding off on this because Doug Barton expressed a strong > desire to drive the process. Since Doug has done considerable work in > this area in the past, I felt it was worth giving him first stab. Thanks for the cc, I was actually following the thread for a change. :) I looked the patch over last night, and I have some concerns, mostly about how we're integrating the new with the old, but I wanted to actually go in and patch my local system and look at the thing in context before I responded in more detail. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 12:39:36 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 AE4BB37B405 for ; Thu, 1 Nov 2001 12:39:33 -0800 (PST) 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 HAA12379; Fri, 2 Nov 2001 07:39:27 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01KA7YH6JEA8VFII07@cim.alcatel.com.au>; Fri, 2 Nov 2001 07:39:15 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id fA1KdOr32077; Fri, 02 Nov 2001 07:39:24 +1100 Content-return: prohibited Date: Fri, 02 Nov 2001 07:39:24 +1100 From: Peter Jeremy Subject: Re: FYI: A thought on 64-bit time_t on Alpha In-reply-to: <20011030225720.A39348@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Tue, Oct 30, 2001 at 10:57:20PM -0800 To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Mail-Followup-To: Marcel Moolenaar , arch@FreeBSD.ORG Message-id: <20011102073924.O94635@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: <20011030225720.A39348@dhcp01.pn.xcllnt.net> Sender: owner-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 2001-Oct-30 22:57:20 -0800, Marcel Moolenaar wrote: >We all seem to be of the opinion that the 64-bit archs should >have a 64-bit time_t. The question that is unanswered at this >time is whether this includes the Alpha. My feeling is that Alpha should move to 64-bit time. I realise that it won't survive to 2038, but it is currently our reference 64-bit platform. Others have pointed out that the pain of porting FreeBSD to a new 64-bit platform will be increased by having to simultaneously manage a changed time_t size WRT i386. This pain can be minimised if the 32-bit dependencies have been weeded out in the Alpha. I should add that I do use FreeBSD on the Alpha (but not for production applications). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 13:14:56 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 06B9337B405 for ; Thu, 1 Nov 2001 13:14:50 -0800 (PST) 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 fA1LEhB08061 for ; Thu, 1 Nov 2001 16:14:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 1 Nov 2001 16:14:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Changes to suser() and friends 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 Currently, in a post-KSE world, we have the following calls relating to the 'superuser' concept: int suser __P((struct proc *)); int suser_td __P((struct thread *)); int suser_xxx __P((struct ucred *cred, struct proc *proc, int flag)); int suser_xxx_td __P((struct ucred *cred, struct thread *thread, int flag)); I'd like to propose they be collapsed into one of the following: (1) Two calls, one with flags, and one without, both accepting ucreds as arguments: int suser __P((struct ucred *)); int suser_xxx __P((struct ucred *cred, int flag)); (2) One call, with flags, accepting a ucred as an argument: int suser __P((struct ucred *cred, int flag)); I don't really mind which it is, but have a slightly preference for suser() without a suser_xxx(), since suser_xxx() has the appearance of a hack. Rationale for the change: (1) suser() no longer requires access to the process or thread structure, since (a) ASU has been deprecated, and (b) prison-related proc contents required for access control have been moved to struct ucred. As such, a ucred is now sufficient. (2) Removal of redundant interfaces. All of these calls are wrappers for suser_xxx(). (3) Simplification of locking and reference management. The new suser call(s) will require only a valid read-only reference to a struct ucred pointer. Existing calls may (depending on arguments) require a references to threads and processes, and conceivably locks on them. The new model allows the caller to select the correct ucred (which the calling code already does, by virtue of selecting what gets passed in). Given that current calling code generally has to now choose between a process and a thread to find the ucred, I don't believe the slightly increased complication of: error = suser(p->p_ucred); or error = suser(td->td_proc->p_ucred); or error = suser(td->td_ucred); is substantial. In fact, given that threads will have access to two credentials (the thread cached credential, and the process credential), making it explicit is probably a very good idea. Assuming there are no objections, I plan to commit this change on Monday. 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 Nov 1 13:40:13 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 4713237B401; Thu, 1 Nov 2001 13:40:11 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA42322; Thu, 1 Nov 2001 13:35:47 -0800 (PST) Date: Thu, 1 Nov 2001 13:35:35 -0800 (PST) From: Julian Elischer To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: Changes to suser() and friends In-Reply-To: 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, 1 Nov 2001, Robert Watson wrote: > > error = suser(p->p_ucred); > or > error = suser(td->td_proc->p_ucred); > or > error = suser(td->td_ucred); the reason for the existance of suser_td is so that it could be called by functions for which 'thread *' was an opaque pointer.. i.e. there are many places that use suser() and suser_td() that do not include proc.h and thus do not know about any sub elements of the thread structure. (or proc structure) by making this change you are forcing these file sto include proc.h. this is not hard, but just another move towards "every file includes every .h file" > > is substantial. In fact, given that threads will have access to two > credentials (the thread cached credential, and the process credential), > making it explicit is probably a very good idea. > > Assuming there are no objections, I plan to commit this change on Monday. > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 1 14:43: 1 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 2FA8F37B405; Thu, 1 Nov 2001 14:42:58 -0800 (PST) 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 fA1Mgip157396; Thu, 1 Nov 2001 17:42:44 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Thu, 1 Nov 2001 17:42:41 -0500 To: Julian Elischer , Robert Watson From: Garance A Drosihn Subject: Re: Changes to suser() and friends 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 1:35 PM -0800 11/1/01, Julian Elischer wrote: >On Thu, 1 Nov 2001, Robert Watson wrote: > >> >> error = suser(p->p_ucred); >> or >> error = suser(td->td_proc->p_ucred); >> or >> error = suser(td->td_ucred); > >the reason for the existance of suser_td is so that it could be called >by functions for which 'thread *' was an opaque pointer.. i.e. there >are many places that use suser() and suser_td() that do not include >proc.h and thus do not know about any sub elements of the thread >structure. (or proc structure) Hmm. It is nicer when fewer source files are mucking around in the internals of a data structure. Still, it would be nice to collapse to fewer routines. Would the following be any better? int suser __P((struct ucred *cred, struct proc *proc, int flag)); int suser_td __P((struct ucred *cred, struct thread *thread, int flag)); and say that the current 'suser(struct proc *)' be done as new 'suser(NULL, struct proc *, 0)', and the current 'suser_td(struct thread *)' be done as new 'suser_td(NULL, struct thread *, 0)' or is that too stupid for words? Or maybe switch the positions of 'cred' and 'proc/thread', just so the most common callers would just have 'NULL, 0' as the last two parameters. Does that add too much overhead? [disclaimer: this is clearly not my area of coding, so it may very well be that the above *is* too stupid for words... :-) ] -- 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 Thu Nov 1 15:30:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.250.130.228]) by hub.freebsd.org (Postfix) with ESMTP id A488037B406; Thu, 1 Nov 2001 15:30:34 -0800 (PST) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.3) with ESMTP id fA1NTkI40804; Thu, 1 Nov 2001 15:29:47 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 1 Nov 2001 15:29:46 -0800 (PST) From: Kelly Yancey To: Garance A Drosihn Cc: Julian Elischer , Robert Watson , arch@FreeBSD.ORG Subject: Re: Changes to suser() and friends In-Reply-To: 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, 1 Nov 2001, Garance A Drosihn wrote: > Hmm. It is nicer when fewer source files are mucking around in the > internals of a data structure. Still, it would be nice to collapse > to fewer routines. Would the following be any better? > > int suser __P((struct ucred *cred, struct proc *proc, int flag)); > int suser_td __P((struct ucred *cred, struct thread *thread, int flag)); > > and say that the current 'suser(struct proc *)' > be done as new 'suser(NULL, struct proc *, 0)', > and the current 'suser_td(struct thread *)' > be done as new 'suser_td(NULL, struct thread *, 0)' > or is that too stupid for words? Or maybe switch the positions of > 'cred' and 'proc/thread', just so the most common callers would just > have 'NULL, 0' as the last two parameters. Does that add too much > overhead? > I acknowledge I have no specific insight into suser(), but I would like to add that if you are going to have two different behaviours keyed off of whether a parameter is NULL or not, it is more logical to have two separate functions representing those behaviours. See realloc as an example of what happens when you overload a function with multiple behaviours keyed off of a parameter value. This is presumably the exact sort of overloading that the current (albeit poorly named) set of functions was intended to avoid. Kelly P.S. I like my bikesheds blue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 8: 9:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from saturn.bsdhome.com (rdu25-2-113.nc.rr.com [24.25.2.113]) by hub.freebsd.org (Postfix) with ESMTP id 2D75B37B403 for ; Fri, 2 Nov 2001 08:09:49 -0800 (PST) Received: from neutrino.bsdhome.com (jupiter [192.168.220.13]) by saturn.bsdhome.com (8.11.3nb1/8.11.4) with ESMTP id fA2G9mk08809 for ; Fri, 2 Nov 2001 11:09:48 -0500 (EST) Received: (from bsd@localhost) by neutrino.bsdhome.com (8.11.6/8.11.6) id fA2G9gY41656; Fri, 2 Nov 2001 11:09:42 -0500 (EST) (envelope-from bsd) Date: Fri, 2 Nov 2001 11:09:42 -0500 From: Brian Dean To: freebsd-arch@freebsd.org Subject: rotation of lastlog Message-ID: <20011102110942.A41614@neutrino.bsdhome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-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, Perhaps this is a dumb question, but is there any reason _not_ to have /var/log/lastlog be rotated via newsyslog like most other log files? I thought that maybe it was omitted because it is composed of fixed format data structures and rotating it at just the wrong time could split one of these structures, throwing off alignment. But I see that wtmp is rotated by newsyslog, which has the same issue. If the above is not a concern or can't happen, or there are no other concerns, I'd like to add it. Any objections? Thanks, -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 8:16:45 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 EE47F37B401 for ; Fri, 2 Nov 2001 08:16:42 -0800 (PST) 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 fA2GFVQ26807 for ; Fri, 2 Nov 2001 08:15:31 -0800 (PST) Received: from [172.30.50.1] by hermes.corp.disney.com with ESMTP for freebsd-arch@FreeBSD.ORG; Fri, 2 Nov 2001 08:15:51 -0800 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 fA2GJJ313926 for ; Fri, 2 Nov 2001 08:19:19 -0800 (PST) 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 IAA06663 for ; Fri, 2 Nov 2001 08:16:40 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from [172.30.5.138] by mercury.fan.fa.disney.com with ESMTP; Fri, 2 Nov 2001 08:16:40 -0800 Message-Id: <3BE2C780.7BCA0B21@disney.com> Date: Fri, 02 Nov 2001 08:19:12 -0800 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: Brian Dean Cc: freebsd-arch@FreeBSD.ORG Subject: Re: rotation of lastlog References: <20011102110942.A41614@neutrino.bsdhome.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 As I understood it, lastlog never really grew in size because there is only 1 entry for each user on your system, and when the logged in, that entry was updated. I also though on some systems, this was a sparse file where the index of your entry was based on the uid. How it is in FreeBSD may not be the same, in that I have not looked into it. - JimP Brian Dean wrote: > > Hi, > > Perhaps this is a dumb question, but is there any reason _not_ to have > /var/log/lastlog be rotated via newsyslog like most other log files? > > I thought that maybe it was omitted because it is composed of fixed > format data structures and rotating it at just the wrong time could > split one of these structures, throwing off alignment. But I see that > wtmp is rotated by newsyslog, which has the same issue. > > If the above is not a concern or can't happen, or there are no other > concerns, I'd like to add it. Any objections? > > Thanks, > -Brian > -- > Brian Dean > bsd@FreeBSD.org > bsd@bsdhome.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- --- @(#) $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 Fri Nov 2 8:24: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mcqueen.wolfsburg.de (pns.wobline.de [212.68.68.5]) by hub.freebsd.org (Postfix) with ESMTP id 4BEB237B401 for ; Fri, 2 Nov 2001 08:24:07 -0800 (PST) Received: from colt.ncptiddische.net (ppp-124.wobline.de [212.68.69.132]) by mcqueen.wolfsburg.de (8.11.3/8.11.3/tw-20010821) with ESMTP id fA2GO3N02689; Fri, 2 Nov 2001 17:24:03 +0100 Received: from howie.ncptiddische.net (howie.ncptiddische.net [192.168.0.3]) by colt.ncptiddische.net (8.11.6/8.11.6) with ESMTP id fA2GQY727866; Fri, 2 Nov 2001 17:26:34 +0100 (CET) (envelope-from nils@tisys.org) Received: from howie.ncptiddische.net (howie.ncptiddische.net [192.168.0.3]) by howie.ncptiddische.net (8.11.6/8.11.6) with ESMTP id fA2GO9r00874; Fri, 2 Nov 2001 17:24:09 +0100 (CET) (envelope-from nils@tisys.org) Date: Fri, 2 Nov 2001 17:24:09 +0100 (CET) From: Nils Holland To: Brian Dean Cc: freebsd-arch@FreeBSD.ORG Subject: Re: rotation of lastlog In-Reply-To: <20011102110942.A41614@neutrino.bsdhome.com> Message-ID: <20011102172208.O869-100000@howie.ncptiddische.net> 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, 2 Nov 2001, Brian Dean wrote: > Hi, > > Perhaps this is a dumb question, but is there any reason _not_ to have > /var/log/lastlog be rotated via newsyslog like most other log files? > > [...] > > If the above is not a concern or can't happen, or there are no other > concerns, I'd like to add it. Any objections? From what I know, you can rotate it via newsyslog just fine andwithout any problems. I don't know if somebody else probably has something noteworthy to add, but I think generally you can just have it rotated. Greetings Nils Nils Holland Ti Systems - FreeBSD in Tiddische, Germany http://www.tisys.org * nils@tisys.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 10: 4:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.noos.fr (lafontaine.noos.net [212.198.2.72]) by hub.freebsd.org (Postfix) with ESMTP id 106E837B401 for ; Fri, 2 Nov 2001 10:04:27 -0800 (PST) Received: (qmail 91349285 invoked by uid 0); 2 Nov 2001 18:04:25 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.72 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Nov 2001 18:04:25 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id fA2I4N697669; Fri, 2 Nov 2001 19:04:23 +0100 (CET) (envelope-from root) Message-Id: <200111021804.fA2I4N697669@gits.dyndns.org> Subject: Re: rotation of lastlog In-Reply-To: <20011102110942.A41614@neutrino.bsdhome.com> To: Brian Dean Date: Fri, 2 Nov 2001 19:04:23 +0100 (CET) Cc: freebsd-arch@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL95a (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 Brian Dean wrote: > > Perhaps this is a dumb question, but is there any reason _not_ to have > /var/log/lastlog be rotated via newsyslog like most other log files? as Jim says, lastlog prabably is a sparse file. so, it don't take so much space on disk. rotating it probably fill up those wholes. so, it will take more space than w/o rotating it except if newsyslog handle well sparse files, but I have a doubt about this since very few commands handle such files right. > I thought that maybe it was omitted because it is composed of fixed > format data structures and rotating it at just the wrong time could > split one of these structures, throwing off alignment. But I see that I think so. > wtmp is rotated by newsyslog, which has the same issue. there is a major difference between lastlog (or utmp) and wtmp, the later can grow indefinitely... > If the above is not a concern or can't happen, or there are no other > concerns, I'd like to add it. Any objections? # cd /var/log # ls -ls lastlog* 24 -rw-rw-r-- 1 root wheel 64568 Nov 2 16:44 lastlog # cp lastlog lastlog.0 # ls -ls lastlog* 24 -rw-rw-r-- 1 root wheel 64568 Nov 2 16:44 lastlog 64 -rw-r--r-- 1 root wheel 64568 Nov 2 19:02 lastlog.0 did that answer your question ? 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 Nov 2 10:10:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from saturn.bsdhome.com (rdu25-2-113.nc.rr.com [24.25.2.113]) by hub.freebsd.org (Postfix) with ESMTP id 6D33F37B401 for ; Fri, 2 Nov 2001 10:10:22 -0800 (PST) Received: from neutrino.bsdhome.com (jupiter [192.168.220.13]) by saturn.bsdhome.com (8.11.3nb1/8.11.4) with ESMTP id fA2IALk09414; Fri, 2 Nov 2001 13:10:21 -0500 (EST) Received: (from bsd@localhost) by neutrino.bsdhome.com (8.11.6/8.11.6) id fA2IAHM42409; Fri, 2 Nov 2001 13:10:17 -0500 (EST) (envelope-from bsd) Date: Fri, 2 Nov 2001 13:10:17 -0500 From: Brian Dean To: Jim Pirzyk Cc: freebsd-arch@FreeBSD.ORG Subject: Re: rotation of lastlog Message-ID: <20011102131017.A42366@neutrino.bsdhome.com> References: <20011102110942.A41614@neutrino.bsdhome.com> <3BE2C780.7BCA0B21@disney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE2C780.7BCA0B21@disney.com>; from Jim.Pirzyk@disney.com on Fri, Nov 02, 2001 at 08:19:12AM -0800 Sender: owner-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, Nov 02, 2001 at 08:19:12AM -0800, Jim Pirzyk wrote: > As I understood it, lastlog never really grew in size because > there is only 1 entry for each user on your system, and when > the logged in, that entry was updated. This seems to be case. Thus, rotating it doesn't make a whole lot of sense, in general. Thanks for the clarification on how this file is used, I won't pursue adding it to newsyslog.conf. -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 10:31:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mcqueen.wolfsburg.de (pns.wobline.de [212.68.68.5]) by hub.freebsd.org (Postfix) with ESMTP id B874C37B408 for ; Fri, 2 Nov 2001 10:31:44 -0800 (PST) Received: from colt.ncptiddische.net (ppp-148.wobline.de [212.68.69.156]) by mcqueen.wolfsburg.de (8.11.3/8.11.3/tw-20010821) with ESMTP id fA2IVSN14645; Fri, 2 Nov 2001 19:31:29 +0100 Received: from jodie.ncptiddische.net (jodie.ncptiddische.net [192.168.0.2]) by colt.ncptiddische.net (8.11.6/8.11.6) with ESMTP id fA2IY0728385; Fri, 2 Nov 2001 19:34:01 +0100 (CET) (envelope-from nils@tisys.org) Received: from jodie.ncptiddische.net (jodie.ncptiddische.net [192.168.0.2]) by jodie.ncptiddische.net (8.11.6/8.11.6) with ESMTP id fA2IVsf02489; Fri, 2 Nov 2001 19:31:54 +0100 (CET) (envelope-from nils@tisys.org) Date: Fri, 2 Nov 2001 19:31:54 +0100 (CET) From: Nils Holland To: Brian Dean Cc: Jim Pirzyk , Subject: Re: rotation of lastlog In-Reply-To: <20011102131017.A42366@neutrino.bsdhome.com> Message-ID: <20011102193106.N2484-100000@jodie.ncptiddische.net> 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, 2 Nov 2001, Brian Dean wrote: > This seems to be case. Thus, rotating it doesn't make a whole lot of > sense, in general. Thanks for the clarification on how this file is > used, I won't pursue adding it to newsyslog.conf. Hmm, well, then at least the answer I posted was not all that wrong: It *could* be rotated, but it probably makes very little sense to do so ;-) Greetings Nils Nils Holland Ti Systems - FreeBSD in Tiddische, Germany http://www.tisys.org * nils@tisys.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 11:24:36 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 C7A2437B403 for ; Fri, 2 Nov 2001 11:24:31 -0800 (PST) Received: (qmail 99449 invoked from network); 2 Nov 2001 19:24:30 -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 ; 2 Nov 2001 19:24:30 -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, 02 Nov 2001 11:24:29 -0800 (PST) From: John Baldwin To: Kelly Yancey Subject: Re: Changes to suser() and friends Cc: arch@FreeBSD.ORG, Robert Watson , Julian Elischer , Garance A Drosihn Sender: owner-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 01-Nov-01 Kelly Yancey wrote: > On Thu, 1 Nov 2001, Garance A Drosihn wrote: > >> Hmm. It is nicer when fewer source files are mucking around in the >> internals of a data structure. Still, it would be nice to collapse >> to fewer routines. Would the following be any better? >> >> int suser __P((struct ucred *cred, struct proc *proc, int flag)); >> int suser_td __P((struct ucred *cred, struct thread *thread, int flag)); >> >> and say that the current 'suser(struct proc *)' >> be done as new 'suser(NULL, struct proc *, 0)', >> and the current 'suser_td(struct thread *)' >> be done as new 'suser_td(NULL, struct thread *, 0)' >> or is that too stupid for words? Or maybe switch the positions of >> 'cred' and 'proc/thread', just so the most common callers would just >> have 'NULL, 0' as the last two parameters. Does that add too much >> overhead? >> > > I acknowledge I have no specific insight into suser(), but I would like to > add that if you are going to have two different behaviours keyed off of > whether a parameter is NULL or not, it is more logical to have two separate > functions representing those behaviours. See realloc as an example of what > happens when you overload a function with multiple behaviours keyed off of a > parameter value. This is presumably the exact sort of overloading that the > current (albeit poorly named) set of functions was intended to avoid. Agreed. After chatting a bit with rwatson on IRC, my conclusion is for the following two functions. I'm not sure worrying over includes is all that valuable, but having drivers and filesystems be able to handle threads and procs in the abstract instead of having to muck with their innards is cleaner. These two functions remove any ambiguity about what ucred is being used as well. int suser(struct thread *td, int flags) Uses td->td_proc->td_ucred for its ucred. Fairly soon it will switch to td->td_ucred when that is safe to do so. Note that this will only be useful for curthread. int suser_cred(struct ucred *cred, int flags) Uses cred for its ucred. Useful in places where you want to use a ucred other than a thread's ucred. suser() really is all about ucreds, so I can appreciate Robert's desire to have one function that just takes a ucred, but I like preserving the existing abstraction of d_thread_t. It will also make keeping code portable between 4.x and 5.x easier. -- 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 Nov 2 12: 0:22 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 8C48F37B407; Fri, 2 Nov 2001 12:00:17 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA47173; Fri, 2 Nov 2001 11:40:47 -0800 (PST) Date: Fri, 2 Nov 2001 11:40:45 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Kelly Yancey , arch@FreeBSD.ORG, Robert Watson , Garance A Drosihn Subject: Re: Changes to suser() and friends In-Reply-To: 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, 2 Nov 2001, John Baldwin wrote: [...] > valuable, but having drivers and filesystems be able to handle threads and > procs in the abstract instead of having to muck with their innards is cleaner. > These two functions remove any ambiguity about what ucred is being used as well. > > int suser(struct thread *td, int flags) > Uses td->td_proc->td_ucred for its ucred. Fairly soon it will switch > to td->td_ucred when that is safe to do so. Note that this will only > be useful for curthread. If it is only useful for curthread (why?) then why specify the thread at all..? just use curthread internally.. (or maybe it IS usable for another thread in some cases?) The problem here, is that there are still plenty of cases where suser() is testing a PROCESS, because there is no indication as to which thread would be chosen to use instead.. e.g. in a function void fred(struct proc *p) { [...] suser(td); /* where did we get that td from? */ [...] } hmmm actually looking in the kernel, I noticed that most of those seem to have gone away anyhow... ignore me.. I plead old-age. > int suser_cred(struct ucred *cred, int flags) > Uses cred for its ucred. Useful in places where you want to > use a ucred other than a thread's ucred. > > suser() really is all about ucreds, so I can appreciate Robert's > desire to have one function that just takes a ucred, but I like > preserving the existing abstraction of d_thread_t. It will also make > keeping code portable between 4.x and 5.x easier. EEK! That was defined as only being useful in the context of device entrypoints..... I see creeping murk here! > > -- > > 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 Nov 2 12: 5:11 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 66E7F37B40A; Fri, 2 Nov 2001 12:05:05 -0800 (PST) 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 fA2K4wB27781; Fri, 2 Nov 2001 15:04:58 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 2 Nov 2001 15:04:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: Kelly Yancey , arch@FreeBSD.org, Julian Elischer , Garance A Drosihn Subject: Re: Changes to suser() and friends In-Reply-To: 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, 2 Nov 2001, John Baldwin wrote: > Agreed. After chatting a bit with rwatson on IRC, my conclusion is for > the following two functions. I'm not sure worrying over includes is all > that valuable, but having drivers and filesystems be able to handle > threads and procs in the abstract instead of having to muck with their > innards is cleaner. These two functions remove any ambiguity about what > ucred is being used as well. This ambiguity was one of my primary concerns with the current interface. > int suser(struct thread *td, int flags) > Uses td->td_proc->td_ucred for its ucred. Fairly soon it will switch > to td->td_ucred when that is safe to do so. Note that this will only > be useful for curthread. > int suser_cred(struct ucred *cred, int flags) > Uses cred for its ucred. Useful in places where you want to use a ucred > other than a thread's ucred. Such as the process ucred, cached struct file ucred, cached struct socket ucred, VFS-provided ucred, ... > suser() really is all about ucreds, so I can appreciate Robert's desire > to have one function that just takes a ucred, but I like preserving the > existing abstraction of d_thread_t. It will also make keeping code > portable between 4.x and 5.x easier. I'm fine with these, and accept the binary compatibility argument: that is, in general it would be nice if drivers did not have to grope around in these structures, improving the data hiding aspect. I suspect, however, an important strategy will be to remove some of the extraneous use of suser() in drivers, which most of the time are able to rely on the file system/device node protections. Given that a move towards fine-grained access control will require added includes in these drivers anyway, so I think on face value the #include concern is somewhat bogus; a strategy of avoiding unnecessary access control in the drivers would address this problem also, however. I'll write up a patch with these changes, and post it for review RSN. 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 Fri Nov 2 12:20:18 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 0B49E37B403 for ; Fri, 2 Nov 2001 12:20:13 -0800 (PST) Received: (qmail 27915 invoked from network); 2 Nov 2001 20:20:11 -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 ; 2 Nov 2001 20:20:11 -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, 02 Nov 2001 12:20:11 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: Changes to suser() and friends Cc: Garance A Drosihn , Robert Watson , arch@FreeBSD.ORG, Kelly Yancey Sender: owner-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 02-Nov-01 Julian Elischer wrote: > > > On Fri, 2 Nov 2001, John Baldwin wrote: > [...] >> valuable, but having drivers and filesystems be able to handle > threads and >> procs in the abstract instead of having to muck with their innards is >> cleaner. >> These two functions remove any ambiguity about what ucred is being used as >> well. >> >> int suser(struct thread *td, int flags) >> Uses td->td_proc->td_ucred for its ucred. Fairly soon it will >> switch >> to td->td_ucred when that is safe to do so. Note that this will >> only >> be useful for curthread. > > If it is only useful for curthread (why?) then why specify the thread at > all..? just use curthread internally.. (or maybe it IS usable for another > thread in some cases?) > The problem here, is that there are still plenty of cases where > suser() is testing a PROCESS, because there is no indication > as to which thread would be chosen to use instead.. > e.g. in a function For compatibility in drivers that call suser() for 4.x and 5.x. I guess also for the same reason we insist on passing down curthread to syscalls and vops instead of assuming curthread. > void > fred(struct proc *p) > { > [...] > suser(td); /* where did we get that td from? */ > [...] > } > > hmmm actually looking in the kernel, I noticed that most of those seem to > have gone away anyhow... ignore me.. I plead old-age. > > >> int suser_cred(struct ucred *cred, int flags) >> Uses cred for its ucred. Useful in places where you want to >> use a ucred other than a thread's ucred. >> >> suser() really is all about ucreds, so I can appreciate Robert's >> desire to have one function that just takes a ucred, but I like >> preserving the existing abstraction of d_thread_t. It will also make >> keeping code portable between 4.x and 5.x easier. > > EEK! That was defined as only being useful in the context of > device entrypoints..... > > I see creeping murk here! And if a device driver is calling suser()? This makes that case easier to maintain for the driver author since the code wont' care if this is a thread or proc, and so a simple #define suser(x,y) suser(x) can be used to make -current code work on -stable. -- 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 Nov 2 12:54: 9 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 1EA4237B403 for ; Fri, 2 Nov 2001 12:54:06 -0800 (PST) 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 fA2Ks4V26309; Fri, 2 Nov 2001 13:54:04 -0700 (MST) (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 fA2Ks3763369; Fri, 2 Nov 2001 13:54:03 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200111022054.fA2Ks3763369@harmony.village.org> To: Jake Burkholder Subject: Re: Makefile unification Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 31 Oct 2001 22:33:47 EST." <20011031223347.B45913@locore.ca> References: <20011031223347.B45913@locore.ca> <200110300442.f9U4gM701469@harmony.village.org> Date: Fri, 02 Nov 2001 13:54:03 -0700 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 <20011031223347.B45913@locore.ca> Jake Burkholder writes: : The first .include should be kern1.mk, not kern2.mk. OK. I messed this up. I'm changing everything to kern.pre.mk and kern.post.mk ala ports. : I've put the modified Makefile.sparc64 up here: : http://people.freebsd.org/~jake/Makefile.sparc64 OK. I've grabbed these. This looks good to me. Sorry that I didn't quite translate it correctly. Any other comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 13: 0:21 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 8215837B403; Fri, 2 Nov 2001 13:00:18 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA47463; Fri, 2 Nov 2001 12:53:23 -0800 (PST) Date: Fri, 2 Nov 2001 12:53:21 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Garance A Drosihn , Robert Watson , arch@FreeBSD.ORG, Kelly Yancey Subject: Re: Changes to suser() and friends In-Reply-To: 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, 2 Nov 2001, John Baldwin wrote: > > For compatibility in drivers that call suser() for 4.x and 5.x. I guess also > for the same reason we insist on passing down curthread to syscalls and vops > instead of assuming curthread. > > > I see creeping murk here! > > And if a device driver is calling suser()? This makes that case easier to > maintain for the driver author since the code wont' care if this is a thread or > proc, and so a simple #define suser(x,y) suser(x) can be used to make > -current code work on -stable. I agree in the case of device drivers.. I thought you were indicationg elsewhere.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 14: 2:33 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 E614637B40A; Fri, 2 Nov 2001 14:02:30 -0800 (PST) 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 fA2M2LB29605; Fri, 2 Nov 2001 17:02:21 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 2 Nov 2001 17:02:20 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: John Baldwin , Garance A Drosihn , arch@FreeBSD.org, Kelly Yancey Subject: Re: Changes to suser() and friends In-Reply-To: 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 Just FYI, it looks like a number of other platforms also use struct ucred * as their primary suser() argument, including OpenBSD. Shared drivers appear to tend to have __FreeBSD__ ifdef's scattered around as a result. Also an FYI, we have countless places where a struct td * isn't passed down, and suser() currently relies on curproc. Once we have td->td_ucred ready, we'll need to fix all those, and more universally pass around the td of choice. 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 Fri Nov 2 14:46:27 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 1986D37B40C for ; Fri, 2 Nov 2001 14:46:22 -0800 (PST) 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 fA2MkLM75482 for ; Fri, 2 Nov 2001 14:46:21 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id ADE5139F0; Fri, 2 Nov 2001 14:46:21 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Nils Holland Cc: Brian Dean , Jim Pirzyk , freebsd-arch@FreeBSD.ORG Subject: Re: rotation of lastlog In-Reply-To: <20011102193106.N2484-100000@jodie.ncptiddische.net> Date: Fri, 02 Nov 2001 14:46:21 -0800 From: Peter Wemm Message-Id: <20011102224621.ADE5139F0@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 Nils Holland wrote: > On Fri, 2 Nov 2001, Brian Dean wrote: > > > This seems to be case. Thus, rotating it doesn't make a whole lot of > > sense, in general. Thanks for the clarification on how this file is > > used, I won't pursue adding it to newsyslog.conf. > > Hmm, well, then at least the answer I posted was not all that wrong: It > *could* be rotated, but it probably makes very little sense to do so ;-) Yes, rotating it is exactly the wrong thing to do - it would defeat the purpose of the file. :-) 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 Nov 2 14:49:21 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 3198237B408 for ; Fri, 2 Nov 2001 14:49:20 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id B4CA314C41; Fri, 2 Nov 2001 23:49:18 +0100 (CET) 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: clefevre@citeweb.net Cc: Brian Dean , freebsd-arch@freebsd.org Subject: Re: rotation of lastlog References: <200111021804.fA2I4N697669@gits.dyndns.org> From: Dag-Erling Smorgrav Date: 02 Nov 2001 23:49:18 +0100 In-Reply-To: <200111021804.fA2I4N697669@gits.dyndns.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 Cyrille Lefevre writes: > as Jim says, lastlog prabably is a sparse file. so, it don't take > so much space on disk. rotating it probably fill up those wholes. > so, it will take more space than w/o rotating it except if newsyslog > handle well sparse files, but I have a doubt about this since very > few commands handle such files right. Newsyslog doesn't need to "handle well sparse files", it just renames the file (unless you ask it to gzip it), so the file itself is not modified at all. 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 Nov 2 15:40:14 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 B850437B40F; Fri, 2 Nov 2001 15:40:10 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA48117; Fri, 2 Nov 2001 15:35:39 -0800 (PST) Date: Fri, 2 Nov 2001 15:35:37 -0800 (PST) From: Julian Elischer To: Robert Watson Cc: John Baldwin , Garance A Drosihn , arch@FreeBSD.org, Kelly Yancey Subject: Re: Changes to suser() and friends In-Reply-To: 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, 2 Nov 2001, Robert Watson wrote: > Just FYI, it looks like a number of other platforms also use struct ucred > * as their primary suser() argument, including OpenBSD. Shared drivers > appear to tend to have __FreeBSD__ ifdef's scattered around as a result. > > Also an FYI, we have countless places where a struct td * isn't passed > down, and suser() currently relies on curproc. Once we have td->td_ucred > ready, we'll need to fix all those, and more universally pass around the > td of choice. That was what I was saying earlier, but it is sometimes not obvious which thread should be passed... > > 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 Fri Nov 2 18:21:56 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 632EB37B408 for ; Fri, 2 Nov 2001 18:21:52 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 229BA14C40; Sat, 3 Nov 2001 03:21:51 +0100 (CET) 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: POSIX character class support for 1Tawk From: Dag-Erling Smorgrav Date: 03 Nov 2001 03:21:50 +0100 Message-ID: Lines: 8 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 --=-=-= See attached patch (which I've also submitted to bwk). DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=awk.diff Index: b.c =================================================================== RCS file: /home/ncvs/src/contrib/one-true-awk/b.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 b.c --- b.c 27 Oct 2001 08:07:37 -0000 1.1.1.1 +++ b.c 3 Nov 2001 01:14:16 -0000 @@ -683,12 +683,44 @@ } } +/* + * Character class definitions conformant to the POSIX locale as + * defined in IEEE P1003.1 draft 7 of June 2001, assuming the source + * and operating character sets are both ASCII (ISO646) or supersets + * thereof. + * + * Note that to avoid overflowing the temporary buffer used in + * relex(), the expanded character class (prior to range expansion) + * must be less than twice the size of their full name. + */ +struct charclass { + const uschar *cc_name; + int cc_namelen; + const uschar *cc_expand; +} charclasses[] = { + { "alnum", 5, "0-9A-Za-z" }, + { "alpha", 5, "A-Za-z" }, + { "blank", 5, " \t" }, + { "cntrl", 5, "\000-\037\177" }, + { "digit", 5, "0-9" }, + { "graph", 5, "\041-\176" }, + { "lower", 5, "a-z" }, + { "print", 5, " \041-\176" }, + { "punct", 5, "\041-\057\072-\100\133-\140\173-\176" }, + { "space", 5, " \f\n\r\t\v" }, + { "upper", 5, "A-Z" }, + { "xdigit", 6, "0-9A-Fa-f" }, + { NULL, 0, NULL }, +}; + int relex(void) /* lexical analyzer for reparse */ { + struct charclass *cc; int c, n; int cflag; static uschar *buf = 0; static int bufsz = 100; + const uschar *p; uschar *bp; switch (c = *prestr++) { @@ -730,6 +762,17 @@ *bp++ = c; /* } else if (c == '\n') { */ /* FATAL("newline in character class %.20s...", lastre); */ + } else if (c == '[' && *prestr == ':') { + for (cc = charclasses; cc->cc_name; cc++) + if (strncmp(prestr + 1, cc->cc_name, cc->cc_namelen) == 0) + break; + if (cc->cc_name != NULL && prestr[1 + cc->cc_namelen] == ':' && + prestr[2 + cc->cc_namelen] == ']') { + prestr += cc->cc_namelen + 3; + for (p = cc->cc_expand; *p; p++) + *bp++ = *p; + } else + *bp++ = c; } else if (c == '\0') { FATAL("nonterminated character class %.20s", lastre); } else if (bp == buf) { /* 1st char is special */ --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 20:38:34 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 45E7B37B410 for ; Fri, 2 Nov 2001 20:38:33 -0800 (PST) Received: (qmail 66965 invoked by uid 1000); 3 Nov 2001 04:38:32 -0000 Date: Fri, 2 Nov 2001 23:38:32 -0500 From: Joe Abley To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011102233831.L25226@buffoon.automagic.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 Sat, Nov 03, 2001 at 03:21:50AM +0100, Dag-Erling Smorgrav wrote: > See attached patch (which I've also submitted to bwk). Shouldn't the character classes used depend on the locale? I thought that was (part of) the point of them. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 21:16:49 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 2E75C37B408 for ; Fri, 2 Nov 2001 21:16:47 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 732E914C2E; Sat, 3 Nov 2001 06:16:45 +0100 (CET) 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: Joe Abley Cc: arch@freebsd.org Subject: Re: POSIX character class support for 1Tawk References: <20011102233831.L25226@buffoon.automagic.org> From: Dag-Erling Smorgrav Date: 03 Nov 2001 06:16:44 +0100 In-Reply-To: <20011102233831.L25226@buffoon.automagic.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 Joe Abley writes: > On Sat, Nov 03, 2001 at 03:21:50AM +0100, Dag-Erling Smorgrav wrote: > > See attached patch (which I've also submitted to bwk). > Shouldn't the character classes used depend on the locale? Yes, but 1Tawk doesn't support locales at all, and in any case there is no (simple and portable) way to obtain an enumeration of the characters comprised in a particular character class (finding and reading the locale definition file is neither simple nor portable). 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 Nov 2 22:22: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 E104E37B408 for ; Fri, 2 Nov 2001 22:22:27 -0800 (PST) Received: (qmail 67796 invoked by uid 1000); 3 Nov 2001 06:22:27 -0000 Date: Sat, 3 Nov 2001 01:22:27 -0500 From: Joe Abley To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011103012226.Q25226@buffoon.automagic.org> References: <20011102233831.L25226@buffoon.automagic.org> 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 Sat, Nov 03, 2001 at 06:16:44AM +0100, Dag-Erling Smorgrav wrote: > Joe Abley writes: > > On Sat, Nov 03, 2001 at 03:21:50AM +0100, Dag-Erling Smorgrav wrote: > > > See attached patch (which I've also submitted to bwk). > > Shouldn't the character classes used depend on the locale? > > Yes, but 1Tawk doesn't support locales at all, and in any case there > is no (simple and portable) way to obtain an enumeration of the > characters comprised in a particular character class (finding and > reading the locale definition file is neither simple nor portable). From a (very) brief inspection, it looks like gawk performs checks against [:alpha:] by calling isalpha(). That suggests that if libc on the platform in question happens to support a locale- sensitive isalpha(), then it will be inherited by gawk. Our isalpha() and friends are locale-sensitive, I think. This approach could be taken with bawk to provide locale-sensitive character classes without explicit demands on a locale API. I don't know much about about locales, though, so this could all be just so much crack-addled nonsense. Apologies if so. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 2 22:24: 4 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 9DDBF37B40B for ; Fri, 2 Nov 2001 22:24:01 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 658FA14C2E; Sat, 3 Nov 2001 07:24:00 +0100 (CET) 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: Joe Abley Cc: arch@freebsd.org Subject: Re: POSIX character class support for 1Tawk References: <20011102233831.L25226@buffoon.automagic.org> <20011103012226.Q25226@buffoon.automagic.org> From: Dag-Erling Smorgrav Date: 03 Nov 2001 07:23:59 +0100 In-Reply-To: <20011103012226.Q25226@buffoon.automagic.org> Message-ID: Lines: 8 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 Joe Abley writes: > Our isalpha() and friends are locale-sensitive, I think. Only if the caller has previously called setlocale(). 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 Nov 3 4:59:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id DCE5437B417 for ; Sat, 3 Nov 2001 04:59:20 -0800 (PST) Received: (qmail 76686 invoked by uid 1000); 3 Nov 2001 12:56:08 -0000 Date: Sat, 3 Nov 2001 14:56:08 +0200 From: Peter Pentchev To: Dag-Erling Smorgrav Cc: Joe Abley , arch@freebsd.org Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011103145608.B76275@straylight.oblivion.bg> Mail-Followup-To: Dag-Erling Smorgrav , Joe Abley , arch@freebsd.org References: <20011102233831.L25226@buffoon.automagic.org> <20011103012226.Q25226@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: ; from des@ofug.org on Sat, Nov 03, 2001 at 07:23:59AM +0100 Sender: owner-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, Nov 03, 2001 at 07:23:59AM +0100, Dag-Erling Smorgrav wrote: > Joe Abley writes: > > Our isalpha() and friends are locale-sensitive, I think. > > Only if the caller has previously called setlocale(). So what's the problem in calling setlocale(LC_ALL, "") early in main() or something, as so many other utilities in our base system already do? G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 3 6:40:18 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 1847D37B416 for ; Sat, 3 Nov 2001 06:40:14 -0800 (PST) Received: from hades.hell.gr (patr530-a154.otenet.gr [212.205.215.154]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id fA3Ee5221032; Sat, 3 Nov 2001 16:40:05 +0200 (EET) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id fA3EZFs09110; Sat, 3 Nov 2001 14:35:15 GMT (envelope-from charon@labs.gr) Date: Sat, 3 Nov 2001 14:35:15 +0000 From: Giorgos Keramidas To: Peter Pentchev Cc: Dag-Erling Smorgrav , Joe Abley , arch@FreeBSD.ORG Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011103143515.D4464@hades.hell.gr> References: <20011102233831.L25226@buffoon.automagic.org> <20011103012226.Q25226@buffoon.automagic.org> <20011103145608.B76275@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011103145608.B76275@straylight.oblivion.bg> 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, Nov 03, 2001 at 02:56:08PM +0200, Peter Pentchev wrote: > On Sat, Nov 03, 2001 at 07:23:59AM +0100, Dag-Erling Smorgrav wrote: > > Joe Abley writes: > > > Our isalpha() and friends are locale-sensitive, I think. > > > > Only if the caller has previously called setlocale(). > > So what's the problem in calling setlocale(LC_ALL, "") > early in main() or something, as so many other utilities in > our base system already do? Unfortunately enough, it's not that simple. You'd have to check for all the possible LC_xxx environment variables. The small program below shows what can happen if you use setlocale() with NULL instead of the correct value. #include #include #include #include #include #define GREEK_ALPHA 0xe1 int main (void) { char *lc; setlocale(LC_ALL, NULL); printf("Using NULL: %s\n", isalpha(GREEK_ALPHA) ? "true" : "false"); if ((lc = getenv("LC_ALL")) == NULL) { fprintf(stderr, "LC_ALL is not defined\n"); exit(1); } setlocale(LC_ALL, lc); printf("Using getenv(): %s\n", isalpha(GREEK_ALPHA) ? "true" : "false"); return 0; } Which gives the output shown below: $ cc -Wall -o blah blah.c $ ./blah Using NULL: false LC_ALL is not defined $ env LC_LANG=el_GR LC_ALL=el_GR.ISO8859-7 ./blah Using NULL: false Using getenv(): true In the second case, of having the proper locale setup in the environment, only when getenv() is used to retrieve the proper value for setlocale() the GREEK_ALPHA character is recognized from isalpha() :/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 3 6:50: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 86AF537B418 for ; Sat, 3 Nov 2001 06:49:55 -0800 (PST) Received: (qmail 51748 invoked by uid 1000); 3 Nov 2001 14:49:33 -0000 Date: Sat, 3 Nov 2001 16:49:33 +0200 From: Peter Pentchev To: Giorgos Keramidas Cc: Dag-Erling Smorgrav , Joe Abley , arch@FreeBSD.ORG Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011103164933.E3551@straylight.oblivion.bg> Mail-Followup-To: Giorgos Keramidas , Dag-Erling Smorgrav , Joe Abley , arch@FreeBSD.ORG References: <20011102233831.L25226@buffoon.automagic.org> <20011103012226.Q25226@buffoon.automagic.org> <20011103145608.B76275@straylight.oblivion.bg> <20011103143515.D4464@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: <20011103143515.D4464@hades.hell.gr>; from charon@labs.gr on Sat, Nov 03, 2001 at 02:35:15PM +0000 Sender: owner-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, Nov 03, 2001 at 02:35:15PM +0000, Giorgos Keramidas wrote: > On Sat, Nov 03, 2001 at 02:56:08PM +0200, Peter Pentchev wrote: > > On Sat, Nov 03, 2001 at 07:23:59AM +0100, Dag-Erling Smorgrav wrote: > > > Joe Abley writes: > > > > Our isalpha() and friends are locale-sensitive, I think. > > > > > > Only if the caller has previously called setlocale(). > > > > So what's the problem in calling setlocale(LC_ALL, "") > > early in main() or something, as so many other utilities in > > our base system already do? > > Unfortunately enough, it's not that simple. You'd have to check for > all the possible LC_xxx environment variables. The small program > below shows what can happen if you use setlocale() with NULL instead > of the correct value. [snip] > $ env LC_LANG=el_GR LC_ALL=el_GR.ISO8859-7 ./blah > Using NULL: false > Using getenv(): true > > In the second case, of having the proper locale setup in the > environment, only when getenv() is used to retrieve the proper value > for setlocale() the GREEK_ALPHA character is recognized from isalpha() :/ Well, I implicitly assumed that LC_ALL was set, as by the FreeBSD sample 'russian' login.conf entry: it defines the 'lang' attribute, which sets LANG, which setlocale(3) interprets as an LC_ALL setting. G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 3 6:57:11 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 0178037B417 for ; Sat, 3 Nov 2001 06:57:08 -0800 (PST) Received: from hades.hell.gr (patr530-a154.otenet.gr [212.205.215.154]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id fA3Ev3202564; Sat, 3 Nov 2001 16:57:03 +0200 (EET) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id fA3Ev2j09456; Sat, 3 Nov 2001 14:57:03 GMT (envelope-from charon@labs.gr) Date: Sat, 3 Nov 2001 14:57:01 +0000 From: Giorgos Keramidas To: Peter Pentchev Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011103145700.E4464@hades.hell.gr> References: <20011102233831.L25226@buffoon.automagic.org> <20011103012226.Q25226@buffoon.automagic.org> <20011103145608.B76275@straylight.oblivion.bg> <20011103143515.D4464@hades.hell.gr> <20011103164933.E3551@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011103164933.E3551@straylight.oblivion.bg> 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, Nov 03, 2001 at 04:49:33PM +0200, Peter Pentchev wrote: > On Sat, Nov 03, 2001 at 02:35:15PM +0000, Giorgos Keramidas wrote: > [snip] > > $ env LC_LANG=el_GR LC_ALL=el_GR.ISO8859-7 ./blah > > Using NULL: false > > Using getenv(): true > > > > In the second case, of having the proper locale setup in the > > environment, only when getenv() is used to retrieve the proper value > > for setlocale() the GREEK_ALPHA character is recognized from isalpha() :/ > > Well, I implicitly assumed that LC_ALL was set, as by the FreeBSD sample > 'russian' login.conf entry: it defines the 'lang' attribute, which > sets LANG, which setlocale(3) interprets as an LC_ALL setting. Aye, my mistake. With proper defaults, and "", this works. You are right :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 3 7:11:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.noos.fr (zola.noos.net [212.198.2.76]) by hub.freebsd.org (Postfix) with ESMTP id 0FE8A37B416 for ; Sat, 3 Nov 2001 07:11:39 -0800 (PST) Received: (qmail 15128605 invoked by uid 0); 3 Nov 2001 15:11:36 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Nov 2001 15:11:36 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id fA3FBYs82494; Sat, 3 Nov 2001 16:11:34 +0100 (CET) (envelope-from root) Message-Id: <200111031511.fA3FBYs82494@gits.dyndns.org> Subject: Re: POSIX character class support for 1Tawk In-Reply-To: <20011103145700.E4464@hades.hell.gr> To: Giorgos Keramidas Date: Sat, 3 Nov 2001 16:11:34 +0100 (CET) Cc: Peter Pentchev , Dag-Erling Smorgrav , arch@FreeBSD.ORG Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL95a (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 Giorgos Keramidas wrote: > On Sat, Nov 03, 2001 at 04:49:33PM +0200, Peter Pentchev wrote: > > On Sat, Nov 03, 2001 at 02:35:15PM +0000, Giorgos Keramidas wrote: > > [snip] > > > $ env LC_LANG=el_GR LC_ALL=el_GR.ISO8859-7 ./blah > > > Using NULL: false > > > Using getenv(): true > > > > > > In the second case, of having the proper locale setup in the > > > environment, only when getenv() is used to retrieve the proper value > > > for setlocale() the GREEK_ALPHA character is recognized from isalpha() :/ > > > > Well, I implicitly assumed that LC_ALL was set, as by the FreeBSD sample > > 'russian' login.conf entry: it defines the 'lang' attribute, which > > sets LANG, which setlocale(3) interprets as an LC_ALL setting. > > Aye, my mistake. > With proper defaults, and "", this works. > You are right :) I suppose this only work under -current, I am right ? 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 Sat Nov 3 7:12:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.noos.fr (claudel.noos.net [212.198.2.83]) by hub.freebsd.org (Postfix) with ESMTP id 1601937B417 for ; Sat, 3 Nov 2001 07:12:54 -0800 (PST) Received: (qmail 11783990 invoked by uid 0); 3 Nov 2001 15:12:52 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Nov 2001 15:12:52 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id fA3FCoS82508; Sat, 3 Nov 2001 16:12:50 +0100 (CET) (envelope-from root) Message-Id: <200111031512.fA3FCoS82508@gits.dyndns.org> Subject: Re: POSIX character class support for 1Tawk In-Reply-To: <20011103145608.B76275@straylight.oblivion.bg> To: Peter Pentchev Date: Sat, 3 Nov 2001 16:12:50 +0100 (CET) Cc: Dag-Erling Smorgrav , Joe Abley , arch@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL95a (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 Peter Pentchev wrote: > On Sat, Nov 03, 2001 at 07:23:59AM +0100, Dag-Erling Smorgrav wrote: > > Joe Abley writes: > > > Our isalpha() and friends are locale-sensitive, I think. > > > > Only if the caller has previously called setlocale(). > > So what's the problem in calling setlocale(LC_ALL, "") > early in main() or something, as so many other utilities in > our base system already do? already done in /usr/ports/lang/nawk (alias 1Tawk). see the patches. 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 Sat Nov 3 7:24:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from casimir.physics.purdue.edu (casimir.physics.purdue.edu [128.210.146.111]) by hub.freebsd.org (Postfix) with ESMTP id 64FE437B417; Sat, 3 Nov 2001 07:24:42 -0800 (PST) Received: from will by casimir.physics.purdue.edu with local (Exim 3.32 #1 (Debian)) id 1602ep-0000Be-00; Sat, 03 Nov 2001 10:24:27 -0500 Date: Sat, 3 Nov 2001 10:24:27 -0500 From: Will Andrews To: Paul Richards Cc: Lyndon Nerenberg , Giorgos Keramidas , Robert Watson , arch@FreeBSD.ORG Subject: Re: GNU Compiler Symlinks Message-ID: <20011103102427.I21260@casimir.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Paul Richards , Lyndon Nerenberg , Giorgos Keramidas , Robert Watson , arch@FreeBSD.ORG References: <200110301650.f9UGof0H009849@atg.aciworldwide.com> <763630000.1004565370@lobster.originative.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <763630000.1004565370@lobster.originative.co.uk> 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 Wed, Oct 31, 2001 at 09:56:10PM -0000, Paul Richards wrote: > > Without discussion there would never be change. I was curious to > > discover the rational for keeping the GNU names for the C compiler > > (but not the other GNU tools). I'm not sure I really received an > > answer, and maybe that's the answer in itself. > > When I originally imported gcc2, for the very first FreeBSD release, I > actually patched it so that it looked like it was cc. Somewhere along the > way this practice stopped for cc but not the other tools. > > It had the benefit in that we could support development versions of gcc > that were installed in /usr/local (ports hadn't been invented then). We > could test newer compilers quite easily that way by just changing CC to be > gcc instead of cc. Likewise, which was an issue at the time with the move > to 2.x versions of gcc, other software that required a newer version of the > compiler could be built using gcc rather than the system's cc. > > I'm not sure who stopped that practice but it was useful. The practice was never stopped. You can install a different compiler on your system and use it. For example, GCC3. Set CC=gcc30. Simple enough. We used to have gcc295 on 3.x for the longest time too. Gcc on FreeBSD as it is is referred to by both 'gcc' and 'cc' for compatibility (i.e. many software packages do not test for whether gcc supports their product but it does, and they use CC=cc). In any case, one of the primary reasons we don't use the GNU names for their utilities is because they cause namespace collisions with other similarly named and similarly utilized tools. Even if one doesn't exist yet, it's safe to assume that it might someday. Hence --program-prefix=g. It's only right in a BSD-centric operating system. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 3 7:27:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 5084A37B417 for ; Sat, 3 Nov 2001 07:27:07 -0800 (PST) Received: (qmail 51919 invoked by uid 1000); 3 Nov 2001 15:26:54 -0000 Date: Sat, 3 Nov 2001 17:26:54 +0200 From: Peter Pentchev To: Cyrille Lefevre Cc: Giorgos Keramidas , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011103172654.F3551@straylight.oblivion.bg> Mail-Followup-To: Cyrille Lefevre , Giorgos Keramidas , Dag-Erling Smorgrav , arch@FreeBSD.ORG References: <20011103145700.E4464@hades.hell.gr> <200111031511.fA3FBYs82494@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: <200111031511.fA3FBYs82494@gits.dyndns.org>; from clefevre@citeweb.net on Sat, Nov 03, 2001 at 04:11:34PM +0100 Sender: owner-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, Nov 03, 2001 at 04:11:34PM +0100, Cyrille Lefevre wrote: > Giorgos Keramidas wrote: > > On Sat, Nov 03, 2001 at 04:49:33PM +0200, Peter Pentchev wrote: > > > On Sat, Nov 03, 2001 at 02:35:15PM +0000, Giorgos Keramidas wrote: > > > [snip] > > > > $ env LC_LANG=el_GR LC_ALL=el_GR.ISO8859-7 ./blah > > > > Using NULL: false > > > > Using getenv(): true > > > > > > > > In the second case, of having the proper locale setup in the > > > > environment, only when getenv() is used to retrieve the proper value > > > > for setlocale() the GREEK_ALPHA character is recognized from isalpha() :/ > > > > > > Well, I implicitly assumed that LC_ALL was set, as by the FreeBSD sample > > > 'russian' login.conf entry: it defines the 'lang' attribute, which > > > sets LANG, which setlocale(3) interprets as an LC_ALL setting. > > > > Aye, my mistake. > > With proper defaults, and "", this works. > > You are right :) > > I suppose this only work under -current, I am right ? Um.. no. The 'russian' login class is in -stable, and I've been using a suitably modified 'bulgarian' login class for the past six months. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 3 8:21:12 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 E00A537B416 for ; Sat, 3 Nov 2001 08:21:10 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 39E2214C40; Sat, 3 Nov 2001 17:21:09 +0100 (CET) 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: Peter Pentchev Cc: Joe Abley , arch@freebsd.org Subject: Re: POSIX character class support for 1Tawk References: <20011102233831.L25226@buffoon.automagic.org> <20011103012226.Q25226@buffoon.automagic.org> <20011103145608.B76275@straylight.oblivion.bg> From: Dag-Erling Smorgrav Date: 03 Nov 2001 17:21:08 +0100 In-Reply-To: <20011103145608.B76275@straylight.oblivion.bg> Message-ID: Lines: 17 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 Peter Pentchev writes: > On Sat, Nov 03, 2001 at 07:23:59AM +0100, Dag-Erling Smorgrav wrote: > > Joe Abley writes: > > > Our isalpha() and friends are locale-sensitive, I think. > > Only if the caller has previously called setlocale(). > So what's the problem in calling setlocale(LC_ALL, "") > early in main() or something, as so many other utilities in > our base system already do? You still have to totally rewrite the character class matching code, instead of simply extending it like I've done. See my earlier comments about enumerating the members of a character or equivalence class. 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 Nov 3 11:43:35 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 C9BBB37B416 for ; Sat, 3 Nov 2001 11:43:32 -0800 (PST) Received: (qmail 76351 invoked by uid 1000); 3 Nov 2001 19:43:32 -0000 Date: Sat, 3 Nov 2001 14:43:32 -0500 From: Joe Abley To: Dag-Erling Smorgrav Cc: Peter Pentchev , arch@freebsd.org Subject: Re: POSIX character class support for 1Tawk Message-ID: <20011103144331.S25226@buffoon.automagic.org> References: <20011102233831.L25226@buffoon.automagic.org> <20011103012226.Q25226@buffoon.automagic.org> <20011103145608.B76275@straylight.oblivion.bg> 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 Sat, Nov 03, 2001 at 05:21:08PM +0100, Dag-Erling Smorgrav wrote: > Peter Pentchev writes: > > On Sat, Nov 03, 2001 at 07:23:59AM +0100, Dag-Erling Smorgrav wrote: > > > Joe Abley writes: > > > > Our isalpha() and friends are locale-sensitive, I think. > > > Only if the caller has previously called setlocale(). > > So what's the problem in calling setlocale(LC_ALL, "") > > early in main() or something, as so many other utilities in > > our base system already do? > > You still have to totally rewrite the character class matching code, > instead of simply extending it like I've done. See my earlier > comments about enumerating the members of a character or equivalence > class. Rather than coding the character classes statically, as you have done, is not it possible to extract the character set for each posix class by expanding corresponding character ranges from _CurrentRuneLocale? This smells unportable (is there a portable interface to that structure?) Hard-coding the strings corresponding to the most common locales in bawk seems sub-optimal, considering that the same information exists elsewhere. The hard-coded strings are guaranteed to be wrong for some locale at some point in the future, if not now. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 3 13:39:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.noos.fr (zola.noos.net [212.198.2.76]) by hub.freebsd.org (Postfix) with ESMTP id 3382237B417 for ; Sat, 3 Nov 2001 13:39:34 -0800 (PST) Received: (qmail 15288777 invoked by uid 0); 3 Nov 2001 21:39:32 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Nov 2001 21:39:32 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id fA3LdPt07724; Sat, 3 Nov 2001 22:39:25 +0100 (CET) (envelope-from root) Message-Id: <200111032139.fA3LdPt07724@gits.dyndns.org> Subject: Re: POSIX character class support for 1Tawk In-Reply-To: <20011103172654.F3551@straylight.oblivion.bg> To: Peter Pentchev Date: Sat, 3 Nov 2001 22:39:25 +0100 (CET) Cc: Giorgos Keramidas , Dag-Erling Smorgrav , arch@FreeBSD.ORG Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL95a (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 Peter Pentchev wrote: > On Sat, Nov 03, 2001 at 04:11:34PM +0100, Cyrille Lefevre wrote: > > Giorgos Keramidas wrote: > > > On Sat, Nov 03, 2001 at 04:49:33PM +0200, Peter Pentchev wrote: > > > > On Sat, Nov 03, 2001 at 02:35:15PM +0000, Giorgos Keramidas wrote: > > > > [snip] > > > > > $ env LC_LANG=el_GR LC_ALL=el_GR.ISO8859-7 ./blah > > > > > Using NULL: false > > > > > Using getenv(): true > > > > > > > > > > In the second case, of having the proper locale setup in the > > > > > environment, only when getenv() is used to retrieve the proper value > > > > > for setlocale() the GREEK_ALPHA character is recognized from isalpha() :/ > > > > > > > > Well, I implicitly assumed that LC_ALL was set, as by the FreeBSD sample > > > > 'russian' login.conf entry: it defines the 'lang' attribute, which > > > > sets LANG, which setlocale(3) interprets as an LC_ALL setting. > > > > > > Aye, my mistake. > > > With proper defaults, and "", this works. > > > You are right :) > > > > I suppose this only work under -current, I am right ? > > Um.. no. The 'russian' login class is in -stable, and I've been > using a suitably modified 'bulgarian' login class for the past > six months. so, why the posted program always returns false ? $ uname -a FreeBSD gits 4.4-STABLE FreeBSD 4.4-STABLE #9: Sun Oct 21 22:55:26 CEST 2001 root@gits:/disk2/4.x-stable/src/sys/compile/CUSTOM i386 $ env LANG=el_GR.ISO8859-7 LC_ALL=el_GR.ISO8859-7 ./blah Using NULL: false Using getenv(): false PS : I've changed setlocale(LC_ALL, NULL) to setlocale(LC_ALL, ""). 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