From owner-freebsd-arch Sun Jan 27 0:35:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 9E9E537B417; Sun, 27 Jan 2002 00:35:43 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0R8ZXh14013; Sun, 27 Jan 2002 11:35:33 +0300 (MSK) (envelope-from ache) Date: Sun, 27 Jan 2002 11:35:30 +0300 From: "Andrey A. Chernov" To: Chad David Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127083529.GA13957@nagual.pp.ru> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127003719.A38420@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i Sender: owner-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, Jan 27, 2002 at 00:37:19 -0700, Chad David wrote: > is the first call to localeconv() that causes errno to be updated when > it calls strtol(). After that localeconv() takes a short cut. So it It is because localeconv() cache its result. > isn't really strtod()'s problem, but localeconv()'s. It looks like it is not localeconv() problem, but incorrect locale problem. > The attached patch fixes this case, and probably others. Comments? Don't do that, fix locale instead. cnv() expected to be called on valid numeric fields only. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 1:46:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id E580E37B400; Sun, 27 Jan 2002 01:46:32 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0R9kRV12912; Sun, 27 Jan 2002 02:46:27 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0R9kQh40931; Sun, 27 Jan 2002 02:46:26 -0700 (MST) (envelope-from davidc) Date: Sun, 27 Jan 2002 02:46:26 -0700 From: Chad David To: "Andrey A. Chernov" Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127024626.B40668@colnta.acns.ab.ca> Mail-Followup-To: "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127083529.GA13957@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127083529.GA13957@nagual.pp.ru>; from ache@nagual.pp.ru on Sun, Jan 27, 2002 at 11:35:30AM +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 On Sun, Jan 27, 2002 at 11:35:30AM +0300, Andrey A. Chernov wrote: > On Sun, Jan 27, 2002 at 00:37:19 -0700, Chad David wrote: > > > is the first call to localeconv() that causes errno to be updated when > > it calls strtol(). After that localeconv() takes a short cut. So it > > It is because localeconv() cache its result. Yes, that is what I ment by "short cut" :). > > > isn't really strtod()'s problem, but localeconv()'s. > > It looks like it is not localeconv() problem, but incorrect locale > problem. Maybe, I don't really know much about the locale code, but it seems the default C monetary locale is all nulls. > > > The attached patch fixes this case, and probably others. Comments? > > Don't do that, fix locale instead. cnv() expected to be called on valid > numeric fields only. How would you fix it? I'm not sure errno should get modified just because a locale has an invalid entry? Do you fix the locale (if so how??), or do you make the code a little more robust? -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 2:49:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 6567A37B400; Sun, 27 Jan 2002 02:49:16 -0800 (PST) Received: from pool0039.cvx22-bradley.dialup.earthlink.net ([209.179.198.39] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Umrh-0004p6-00; Sun, 27 Jan 2002 02:48:49 -0800 Message-ID: <3C53DB0B.6547EB76@mindspring.com> Date: Sun, 27 Jan 2002 02:48:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chad David Cc: "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> 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 Chad David wrote: > I just noticed that if you call printf() (or anything that will call > localeconv()) before you call strtod() etc. it works as it should. It > is the first call to localeconv() that causes errno to be updated when > it calls strtol(). After that localeconv() takes a short cut. So it > isn't really strtod()'s problem, but localeconv()'s. Good catch! > The attached patch fixes this case, and probably others. Comments? Uh, working around the problem this way adds overhead to a lot of places where it wasn't before. How about just initializing the shortcut completely? Worse comes to worse, call localeconv() in a .init by abusing the G++ linker set that gets run to construct virtual base clases and template classes the first time. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 2:53:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 7DE8F37B402; Sun, 27 Jan 2002 02:53:06 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0RAr1Z14882; Sun, 27 Jan 2002 13:53:01 +0300 (MSK) (envelope-from ache) Date: Sun, 27 Jan 2002 13:52:59 +0300 From: "Andrey A. Chernov" To: Chad David Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127105258.GA14836@nagual.pp.ru> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127083529.GA13957@nagual.pp.ru> <20020127024626.B40668@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127024626.B40668@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i Sender: owner-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, Jan 27, 2002 at 02:46:26 -0700, Chad David wrote: > How would you fix it? I'm not sure errno should get modified just because > a locale has an invalid entry? Do you fix the locale (if so how??), or do > you make the code a little more robust? I see no invaliad entries in -current default monetary locale. Your code base seems a bit obsoleted, run your tests on -current and report back. Your patch is not for -current too, cnv is different in -current. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 7:17:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from columbus.cris.net (columbus.cris.net [212.110.128.65]) by hub.freebsd.org (Postfix) with ESMTP id EC9B537B400; Sun, 27 Jan 2002 07:17:35 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by columbus.cris.net (8.9.3/8.9.3) with ESMTP id RAA30916; Sun, 27 Jan 2002 17:17:27 +0200 (EET) Received: (from ml@localhost) by phantom.cris.net (8.11.1/8.11.1) id g0RFJPV14864; Sun, 27 Jan 2002 17:19:25 +0200 (EET) (envelope-from ml) Date: Sun, 27 Jan 2002 17:19:25 +0200 From: Alexey Zelkin To: Chad David Cc: "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127171925.A14791@phantom.cris.net> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127003719.A38420@colnta.acns.ab.ca>; from davidc@acns.ab.ca on Sun, Jan 27, 2002 at 12:37:19AM -0700 X-Operating-System: FreeBSD 4.2-STABLE 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 hi, On Sun, Jan 27, 2002 at 12:37:19AM -0700, Chad David wrote: > The attached patch fixes this case, and probably others. Comments? > > Index: localeconv.c > =================================================================== > RCS file: /mnt1/ncvs/src/lib/libc/locale/localeconv.c,v > retrieving revision 1.3 > diff -u -d -r1.3 localeconv.c > --- localeconv.c 10 Feb 2001 02:00:56 -0000 1.3 ^^^^^^^^^^^ > +++ localeconv.c 27 Jan 2002 07:28:51 -0000 ^^^^^^^^^^^ You current seems too old. And I'd suggest to update it first before making tests. At the begining of the last year many locale oriented things were changed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 7:20:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from columbus.cris.net (columbus.cris.net [212.110.128.65]) by hub.freebsd.org (Postfix) with ESMTP id 0038537B416; Sun, 27 Jan 2002 07:20:51 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by columbus.cris.net (8.9.3/8.9.3) with ESMTP id RAA31360; Sun, 27 Jan 2002 17:20:47 +0200 (EET) Received: (from ml@localhost) by phantom.cris.net (8.11.1/8.11.1) id g0RFMoR14899; Sun, 27 Jan 2002 17:22:50 +0200 (EET) (envelope-from ml) Date: Sun, 27 Jan 2002 17:22:50 +0200 From: Alexey Zelkin To: Terry Lambert Cc: Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127172250.B14791@phantom.cris.net> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <3C53DB0B.6547EB76@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C53DB0B.6547EB76@mindspring.com>; from tlambert2@mindspring.com on Sun, Jan 27, 2002 at 02:48:43AM -0800 X-Operating-System: FreeBSD 4.2-STABLE 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 hi, On Sun, Jan 27, 2002 at 02:48:43AM -0800, Terry Lambert wrote: > Chad David wrote: > > I just noticed that if you call printf() (or anything that will call > > localeconv()) before you call strtod() etc. it works as it should. It > > is the first call to localeconv() that causes errno to be updated when > > it calls strtol(). After that localeconv() takes a short cut. So it > > isn't really strtod()'s problem, but localeconv()'s. > > Good catch! > > > The attached patch fixes this case, and probably others. Comments? > > Uh, working around the problem this way adds overhead to a > lot of places where it wasn't before. How about just > initializing the shortcut completely? > > Worse comes to worse, call localeconv() in a .init by abusing > the G++ linker set that gets run to construct virtual base > clases and template classes the first time. Heh! I'm not a linker guru, so could you please explain problem more deeply ? And in case if it's actually problem -- it will be fixed. It's important now since I am going to merge many locale specific changes to STABLE soon. And would like to have it as more clean as possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 12: 6:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 5180837B402; Sun, 27 Jan 2002 12:06:36 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0RK6QV14686; Sun, 27 Jan 2002 13:06:26 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0RK6Pg42805; Sun, 27 Jan 2002 13:06:25 -0700 (MST) (envelope-from davidc) Date: Sun, 27 Jan 2002 13:06:25 -0700 From: Chad David To: "Andrey A. Chernov" Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127130625.A42735@colnta.acns.ab.ca> Mail-Followup-To: "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127083529.GA13957@nagual.pp.ru> <20020127024626.B40668@colnta.acns.ab.ca> <20020127105258.GA14836@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127105258.GA14836@nagual.pp.ru>; from ache@nagual.pp.ru on Sun, Jan 27, 2002 at 01:52:59PM +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 On Sun, Jan 27, 2002 at 01:52:59PM +0300, Andrey A. Chernov wrote: > On Sun, Jan 27, 2002 at 02:46:26 -0700, Chad David wrote: > > > How would you fix it? I'm not sure errno should get modified just because > > a locale has an invalid entry? Do you fix the locale (if so how??), or do > > you make the code a little more robust? > > I see no invaliad entries in -current default monetary locale. Your code > base seems a bit obsoleted, run your tests on -current and report back. > Your patch is not for -current too, cnv is different in -current. Sorry I had grabbed an earlier version of localeconv.c (1.3) after one of bde's comments. Really the differences between 1.3 and 1.9 are very minor and do not affect this problem (other then my patch wouldn't work). As I said, I don't really understand the locale code, but this structure is being returned empty (I have a statically linked libc, and I walked the whole thing in gdb). If I am missing something obvious please point in out to me :). (gdb) info line Line 86 of "/mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/localeconv.c" starts at address 0x8050d0e and ends at 0x8050d16 . (gdb) p mptr $3 = (struct lc_monetary_T *) 0x80529c0 (gdb) p *mptr $4 = {int_curr_symbol = 0x80549ac "", currency_symbol = 0x80549ac "", mon_decimal_point = 0x80549ac "", mon_thousands_sep = 0x80549ac "", mon_grouping = 0x80549ad "\177", positive_sign = 0x80549ac "", negative_sign = 0x80549ac "", int_frac_digits = 0x80549ad "\177", frac_digits = 0x80549ad "\177", p_cs_precedes = 0x80549ad "\177", p_sep_by_space = 0x80549ad "\177", n_cs_precedes = 0x80549ad "\177", n_sep_by_space = 0x80549ad "\177", p_sign_posn = 0x80549ad "\177", n_sign_posn = 0x80549ad "\177"} colnta->cvs status lmonetary.c =================================================================== File: lmonetary.c Status: Up-to-date Working revision: 1.11 Fri Jan 18 09:14:39 2002 Repository revision: 1.11 /mnt1/ncvs/src/lib/libc/locale/lmonetary.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) This looks pretty empty to me. ... static char empty[] = ""; static char numempty[] = { CHAR_MAX, '\0'}; static const struct lc_monetary_T _C_monetary_locale = { empty, /* int_curr_symbol */ empty, /* currency_symbol */ empty, /* mon_decimal_point */ empty, /* mon_thousands_sep */ numempty, /* mon_grouping */ empty, /* positive_sign */ empty, /* negative_sign */ numempty, /* int_frac_digits */ numempty, /* frac_digits */ numempty, /* p_cs_precedes */ numempty, /* p_sep_by_space */ numempty, /* n_cs_precedes */ numempty, /* n_sep_by_space */ numempty, /* p_sign_posn */ numempty /* n_sign_posn */ }; ... -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 12:11:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 5923737B419; Sun, 27 Jan 2002 12:11:26 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0RKBPV14710; Sun, 27 Jan 2002 13:11:25 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0RKBPY42827; Sun, 27 Jan 2002 13:11:25 -0700 (MST) (envelope-from davidc) Date: Sun, 27 Jan 2002 13:11:25 -0700 From: Chad David To: Alexey Zelkin Cc: Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127131125.B42735@colnta.acns.ab.ca> Mail-Followup-To: Alexey Zelkin , Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127171925.A14791@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127171925.A14791@phantom.cris.net>; from phantom@FreeBSD.ORG on Sun, Jan 27, 2002 at 05:19:25PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 27, 2002 at 05:19:25PM +0200, Alexey Zelkin wrote: > hi, > > On Sun, Jan 27, 2002 at 12:37:19AM -0700, Chad David wrote: > > > The attached patch fixes this case, and probably others. Comments? > > > > Index: localeconv.c > > =================================================================== > > RCS file: /mnt1/ncvs/src/lib/libc/locale/localeconv.c,v > > retrieving revision 1.3 > > diff -u -d -r1.3 localeconv.c > > --- localeconv.c 10 Feb 2001 02:00:56 -0000 1.3 > ^^^^^^^^^^^ > > +++ localeconv.c 27 Jan 2002 07:28:51 -0000 > ^^^^^^^^^^^ > > You current seems too old. And I'd suggest to update it first before > making tests. At the begining of the last year many locale oriented things > were changed. > Just this one file (as I mentioned in my last email) :(. The differences between 1.3 are pretty minor though, and they do not affect this. colnta->cvs diff -ud -r 1.3 localeconv.c Index: localeconv.c =================================================================== RCS file: /mnt1/ncvs/src/lib/libc/locale/localeconv.c,v retrieving revision 1.3 retrieving revision 1.9 diff -u -d -r1.3 -r1.9 --- localeconv.c 10 Feb 2001 02:00:56 -0000 1.3 +++ localeconv.c 20 Dec 2001 15:30:02 -0000 1.9 [cut copyright] @@ -29,11 +36,13 @@ #if 0 static char sccsid[] = "@(#)localeconv.c 8.1 (Berkeley) 6/4/93"; #endif -static char rcsid[] = "$FreeBSD: src/lib/libc/locale/localeconv.c,v 1.3 2001/02/10 02:00:56 ache Exp $"; +static char rcsid[] = + "$FreeBSD: src/lib/libc/locale/localeconv.c,v 1.9 2001/12/20 15:30:02 phantom Exp $"; #endif /* LIBC_SCCS and not lint */ #include #include +#include #include "lmonetary.h" #include "lnumeric.h" @@ -51,7 +60,10 @@ static char cnv(char *str) { - return (char)strtol(str, NULL, 0); + int i = strtol(str, NULL, 10); + if (i == -1) + i = CHAR_MAX; + return (char)i; } This change here detected that strtol() was failing, but didn't fix errno. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 12:24:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 41ACE37B404; Sun, 27 Jan 2002 12:24:46 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0RKOeV14738; Sun, 27 Jan 2002 13:24:40 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0RKOe062103; Sun, 27 Jan 2002 13:24:40 -0700 (MST) (envelope-from davidc) Date: Sun, 27 Jan 2002 13:24:40 -0700 From: Chad David To: Terry Lambert Cc: "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127132439.C42735@colnta.acns.ab.ca> Mail-Followup-To: Terry Lambert , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <3C53DB0B.6547EB76@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C53DB0B.6547EB76@mindspring.com>; from tlambert2@mindspring.com on Sun, Jan 27, 2002 at 02:48:43AM -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 Sun, Jan 27, 2002 at 02:48:43AM -0800, Terry Lambert wrote: > Chad David wrote: > > I just noticed that if you call printf() (or anything that will call > > localeconv()) before you call strtod() etc. it works as it should. It > > is the first call to localeconv() that causes errno to be updated when > > it calls strtol(). After that localeconv() takes a short cut. So it > > isn't really strtod()'s problem, but localeconv()'s. > > Good catch! > > > The attached patch fixes this case, and probably others. Comments? > > Uh, working around the problem this way adds overhead to a > lot of places where it wasn't before. How about just > initializing the shortcut completely? > > Worse comes to worse, call localeconv() in a .init by abusing > the G++ linker set that gets run to construct virtual base > clases and template classes the first time. This will not work, as somebody will eventually change the locale, which could cause this to happen again (once) for some unlucky function. Even strtod() (which is where I first noticed this) will only fail the first time. Saving and restoring errno does seem like a hack to me, but I'm not sure how to fix this so bad locales do not break functions (ie strtod()) in none obvious ways. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 14:45:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 0DC1337B400; Sun, 27 Jan 2002 14:45:41 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0RMjWW20097; Mon, 28 Jan 2002 01:45:33 +0300 (MSK) (envelope-from ache) Date: Mon, 28 Jan 2002 01:45:30 +0300 From: "Andrey A. Chernov" To: Chad David Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127224529.GA20003@nagual.pp.ru> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127083529.GA13957@nagual.pp.ru> <20020127024626.B40668@colnta.acns.ab.ca> <20020127105258.GA14836@nagual.pp.ru> <20020127130625.A42735@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127130625.A42735@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i Sender: owner-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, Jan 27, 2002 at 13:06:25 -0700, Chad David wrote: > $4 = {int_curr_symbol = 0x80549ac "", currency_symbol = 0x80549ac "", > mon_decimal_point = 0x80549ac "", mon_thousands_sep = 0x80549ac "", > mon_grouping = 0x80549ad "\177", positive_sign = 0x80549ac "", > negative_sign = 0x80549ac "", int_frac_digits = 0x80549ad "\177", > frac_digits = 0x80549ad "\177", p_cs_precedes = 0x80549ad "\177", > p_sep_by_space = 0x80549ad "\177", n_cs_precedes = 0x80549ad "\177", > n_sep_by_space = 0x80549ad "\177", p_sign_posn = 0x80549ad "\177", > n_sign_posn = 0x80549ad "\177"} > It looks right. cnv() must be never called on that, it already converted. From where failing cnv() call occurse, on which field? Post your minimal test, at least. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 14:54:17 2002 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 B3F4537B416 for ; Sun, 27 Jan 2002 14:54:11 -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 JAA27691; Mon, 28 Jan 2002 09:54:06 +1100 Date: Mon, 28 Jan 2002 09:55:59 +1100 (EST) From: Bruce Evans X-X-Sender: To: Chad David Cc: Subject: Re: strtod() In-Reply-To: <20020126142734.A7139@colnta.acns.ab.ca> Message-ID: <20020128094055.U39729-100000@gamplex.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 Sat, 26 Jan 2002, Chad David wrote: > On Sun, Jan 27, 2002 at 07:44:20AM +1100, Bruce Evans wrote: > > On Thu, 24 Jan 2002, Chad David wrote: > > > > > On current (as of today) strtod() sets errno to EINVAL even when no error > > > ... > > > Note that on stable errno does not get set to EINVAL. > > > > I think you mean strtol(). strtod() hasn't changed significantly since > > RELENG_4. The integer strto*() functions now set it in the following > > Depending on what you mean by "you mean strtol()"? strtol() is being called > indirectly by strtod() via localeconv(), and it is failing (since around > 1.3 or localeconv.c). Oops. I didn't notice this because my version of strtol() doesn't set errno to EINVAL since I don't like that change. It is a POSIX.1-2001 extension, so portable programs can't depend on it; in practice it mainly exposes the brokenness of broken code like FreeBSD's cnv(). More in a reply to later mail... > > %%% > > errno = 0; > > num = strtouq(val, &expr, 0); > > if (errno != 0) /* Overflow or underflow. */ > > err(1, "%s", oper); > > > > if (expr == val) /* No valid digits. */ > > errx(1, "%s: illegal numeric value", oper); > > %%% > > [... This is broken because the "No valid digits" case may, and now > > does set errno. > > Code like this is what I'm dealing with. My point is that if you set > errno == 0, and then after the function it is != 0, an error DID occur, > as long as the return value == 0.0 or HUGE_VAL I guess. For the strto*() family, yes (not for functions that aren't specified to set errno), except you can trust errno if it is set (if the implementation is not broken). More in a reply to later mail... Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 15:16:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 0AD5837B404; Sun, 27 Jan 2002 15:16:33 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0RNGQV15069; Sun, 27 Jan 2002 16:16:26 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0RNGQk62404; Sun, 27 Jan 2002 16:16:26 -0700 (MST) (envelope-from davidc) Date: Sun, 27 Jan 2002 16:16:26 -0700 From: Chad David To: "Andrey A. Chernov" Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127161626.A62332@colnta.acns.ab.ca> Mail-Followup-To: "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127083529.GA13957@nagual.pp.ru> <20020127024626.B40668@colnta.acns.ab.ca> <20020127105258.GA14836@nagual.pp.ru> <20020127130625.A42735@colnta.acns.ab.ca> <20020127224529.GA20003@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127224529.GA20003@nagual.pp.ru>; from ache@nagual.pp.ru on Mon, Jan 28, 2002 at 01:45:30AM +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 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 28, 2002 at 01:45:30AM +0300, Andrey A. Chernov wrote: > On Sun, Jan 27, 2002 at 13:06:25 -0700, Chad David wrote: > > > $4 = {int_curr_symbol = 0x80549ac "", currency_symbol = 0x80549ac "", > > mon_decimal_point = 0x80549ac "", mon_thousands_sep = 0x80549ac "", > > mon_grouping = 0x80549ad "\177", positive_sign = 0x80549ac "", > > negative_sign = 0x80549ac "", int_frac_digits = 0x80549ad "\177", > > frac_digits = 0x80549ad "\177", p_cs_precedes = 0x80549ad "\177", > > p_sep_by_space = 0x80549ad "\177", n_cs_precedes = 0x80549ad "\177", > > n_sep_by_space = 0x80549ad "\177", p_sign_posn = 0x80549ad "\177", > > n_sign_posn = 0x80549ad "\177"} > > > > It looks right. cnv() must be never called on that, it already converted. I don't understand what you mean. > From where failing cnv() call occurse, on which field? Post your minimal > test, at least. > I've attached the simple program I'm using to test, as well as the gdb session that should explain what I am doing. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="strtod.c" #include #include #include #include int main(int argc, char **argv) { double d; char *c; int i; if (argc != 2) { fprintf(stderr, "Usage: %s [double]\n", argv[0]); exit(1); } for (i = 0; i < 2 ; i++) { errno = 0; d = strtod(argv[1], &c); if (d == 0.0 && errno == EINVAL) printf("strtod() failed 1 [%d]\n", i); if (d == 0.0 && c == argv[1]) printf("strtod() failed 2 [%d]\n", i); printf("strtod() returned %f [%d]\n", d, i); } exit(0); } --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=gdb1 colnta->gdb strtod /usr/home/davidc/tmp/strtod GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (gdb) b strtod Breakpoint 1 at 0x804c484: file /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/stdlib/strtod.c, line 1201. (gdb) run 0.0 Starting program: /mnt1/home/davidc/tmp/strtod/strtod 0.0 Breakpoint 1, strtod (s00=0xbfbff82c "0.0", se=0xbfbff6ac) at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/stdlib/strtod.c:1201 1201 char decimal_point = localeconv()->decimal_point[0]; (gdb) s localeconv () at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/localeconv.c:77 77 if (__mlocale_changed) { (gdb) s 84 mptr = __get_current_monetary_locale(); (gdb) s __get_current_monetary_locale () at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/lmonetary.c:81 81 return (_monetary_using_locale (gdb) s localeconv () at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/localeconv.c:85 85 M_ASSIGN_STR(int_curr_symbol); (gdb) p mptr $1 = (struct lc_monetary_T *) 0x8052a20 (gdb) p *mptr $2 = {int_curr_symbol = 0x8054a0c "", currency_symbol = 0x8054a0c "", mon_decimal_point = 0x8054a0c "", mon_thousands_sep = 0x8054a0c "", mon_grouping = 0x8054a0d "\177", positive_sign = 0x8054a0c "", negative_sign = 0x8054a0c "", int_frac_digits = 0x8054a0d "\177", frac_digits = 0x8054a0d "\177", p_cs_precedes = 0x8054a0d "\177", p_sep_by_space = 0x8054a0d "\177", n_cs_precedes = 0x8054a0d "\177", n_sep_by_space = 0x8054a0d "\177", p_sign_posn = 0x8054a0d "\177", n_sign_posn = 0x8054a0d "\177"} (gdb) s 86 M_ASSIGN_STR(currency_symbol); (gdb) s 87 M_ASSIGN_STR(mon_decimal_point); (gdb) s 88 M_ASSIGN_STR(mon_thousands_sep); (gdb) s 89 M_ASSIGN_STR(mon_grouping); (gdb) s 90 M_ASSIGN_STR(positive_sign); (gdb) s 91 M_ASSIGN_STR(negative_sign); (gdb) s 92 M_ASSIGN_CHAR(int_frac_digits); (gdb) s cnv (str=0x8054a0d "\177") at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/localeconv.c:63 63 int i = strtol(str, NULL, 10); (gdb) s strtol (nptr=0x8054a0d "\177", endptr=0x0, base=10) at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/stdlib/strtol.c:69 69 s = nptr; (gdb) s 71 c = *s++; (gdb) s 72 } while (isspace((unsigned char)c)); (gdb) s 152 return ((_c < 0 || _c >= _CACHED_RUNES) ___runetype(_c) : (gdb) s 72 } while (isspace((unsigned char)c)); 73 if (c == '-') { (gdb) s 77 neg = 0; (gdb) s 78 if (c == '+') (gdb) s 81 if ((base == 0 || base == 16) && (gdb) s 87 if (base == 0) (gdb) s 89 acc = any = 0; (gdb) s 90 if (base < 2 || base > 36) (gdb) s 110 cutoff = neg (unsigned long)-(LONG_MIN + LONG_MAX) + LONG_MAX (gdb) s 113 cutoff /= base; (gdb) s 114 for ( ; ; c = *s++) { (gdb) s 115 if (c >= '0' && c <= '9') (gdb) s 117 else if (c >= 'A' && c <= 'Z') (gdb) s 119 else if (c >= 'a' && c <= 'z') (gdb) s 133 if (any < 0) { (gdb) s 138 errno = EINVAL; (gdb) s __error_unthreaded () at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/sys/__error.c:48 48 return(&errno); (gdb) s strtol (nptr=0x8054a0d "\177", endptr=0x0, base=10) at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/stdlib/strtol.c:139 139 } else if (neg) (gdb) s 141 if (endptr != NULL) (gdb) s 143 return (acc); (gdb) s cnv (str=0x8054a0d "\177") at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/localeconv.c:64 64 if (i == -1) (gdb) s 66 return (char)i; (gdb) s localeconv () at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/localeconv.c:93 93 M_ASSIGN_CHAR(frac_digits); (gdb) s cnv (str=0x8054a0d "\177") at /mnt1/devel/work/dev/bsd/FreeBSD/src/lib/libc/../libc/locale/localeconv.c:63 63 int i = strtol(str, NULL, 10); (gdb)p str $3 = 0x8054a0d "\177" (gdb) p errno $4 = 22 --8t9RHnE3ZwKMSgU+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 15:27:41 2002 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 591C337B400; Sun, 27 Jan 2002 15:27:36 -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 KAA29584; Mon, 28 Jan 2002 10:27:19 +1100 Date: Mon, 28 Jan 2002 10:29:13 +1100 (EST) From: Bruce Evans X-X-Sender: To: Chad David Cc: "Andrey A. Chernov" , "Brian F. Feldman" , Subject: Re: strtod() In-Reply-To: <20020127024626.B40668@colnta.acns.ab.ca> Message-ID: <20020128100000.T39789-100000@gamplex.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, 27 Jan 2002, Chad David wrote: > On Sun, Jan 27, 2002 at 11:35:30AM +0300, Andrey A. Chernov wrote: > > It looks like it is not localeconv() problem, but incorrect locale > > problem. > > Maybe, I don't really know much about the locale code, but it seems the > default C monetary locale is all nulls. It always calls cnv() on the string "\0177" here. This is the default for the C locale. From lmonetary.c: static char empty[] = ""; static char numempty[] = { CHAR_MAX, '\0'}; % static const struct lc_monetary_T _C_monetary_locale = { % empty, /* int_curr_symbol */ % empty, /* currency_symbol */ % empty, /* mon_decimal_point */ % empty, /* mon_thousands_sep */ % numempty, /* mon_grouping */ % empty, /* positive_sign */ % empty, /* negative_sign */ % numempty, /* int_frac_digits */ % numempty, /* frac_digits */ % numempty, /* p_cs_precedes */ % numempty, /* p_sep_by_space */ % numempty, /* n_cs_precedes */ % numempty, /* n_sep_by_space */ % numempty, /* p_sign_posn */ % numempty /* n_sign_posn */ % }; > > > The attached patch fixes this case, and probably others. Comments? > > > > Don't do that, fix locale instead. cnv() expected to be called on valid > > numeric fields only. "\0177" isn't very valid :-). > How would you fix it? I'm not sure errno should get modified just because > a locale has an invalid entry? Do you fix the locale (if so how??), or do > you make the code a little more robust? % Index: localeconv.c % =================================================================== % RCS file: /mnt1/ncvs/src/lib/libc/locale/localeconv.c,v % retrieving revision 1.3 % diff -u -d -r1.3 localeconv.c % --- localeconv.c 10 Feb 2001 02:00:56 -0000 1.3 % +++ localeconv.c 27 Jan 2002 07:28:51 -0000 % @@ -49,9 +49,16 @@ % int __mlocale_changed = 1; % int __nlocale_changed = 1; % % +extern int errno; /* required in cnv() */ % + % static char % cnv(char *str) { % - return (char)strtol(str, NULL, 0); % + int save_errno = errno; % + char ret; % + % + ret = (char)strtol(str, NULL, 0); % + errno = save_errno; % + return (ret); % } % % /* This seems reasonable, except: (1) it breaks the threaded case (errno might not be "extern int") (2) it breaks the style rule about inintializing variables in declarations (I might agree with "const int save_errno = errno"). (3) it makes the broken error handling more obvious (cnv() doesn't check for errors from strtol(), and it truncates the value to a char without checking for overflow). Perhaps errors "can't happen", but they just happened. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 16: 8: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 5DB9C37B402; Sun, 27 Jan 2002 16:08:03 -0800 (PST) Received: from pool0437.cvx22-bradley.dialup.earthlink.net ([209.179.199.182] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UzL6-0000n6-00; Sun, 27 Jan 2002 16:08:01 -0800 Message-ID: <3C549659.13EEA86C@mindspring.com> Date: Sun, 27 Jan 2002 16:07:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexey Zelkin Cc: Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <3C53DB0B.6547EB76@mindspring.com> <20020127172250.B14791@phantom.cris.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alexey Zelkin wrote: > Heh! I'm not a linker guru, so could you please explain problem more > deeply ? And in case if it's actually problem -- it will be fixed. > > It's important now since I am going to merge many locale specific changes > to STABLE soon. And would like to have it as more clean as possible. /usr/src/lib/csu/i386-elf/ Look at how _init: is defined in crti.S, and look for the definition of "monstartup()", and its use in crt1.c. Basically, this is code that gets called before any user code. In Windows terms, this is where you would put "process attach" functions for starting things like apartment model threading for a COM/OLE component in a DLL. The "process detach" is basically the "atexit". FreeBSD and Linux still don't have a "thread attach/detach", so don't get your hopes up, if you're a Windows programmer: there's still cool things you simply can't do. 8-). The G++ abuse is for the constructors. There's a linker set called "ctor_list"; this is executed by dereferencing the function pointer from the list (not in a particular order... bad for C++, actually) from the function "do_ctors" in the file /usr/src/lib/csu/common/crtbegin.c . To "abuse" this, all you have to do is add a function to the linker set, using an asm directive, and the function will get called around the time the constructors are called. If you think it's important to call your function earlier than any constructors, this might not be the way to go. This code file, BTW, also has use of the "attribute" directive to show you how to get things into specific named sections (if you care). Bruce can probably give you better information than this (actual code snippets) that I would have to sit down an work out for 15 minutes, whereas he could provide them off the top of his head, I think. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 16:26:42 2002 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 3462137B400 for ; Sun, 27 Jan 2002 16:26:36 -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 LAA00807; Mon, 28 Jan 2002 11:25:50 +1100 Date: Mon, 28 Jan 2002 11:27:44 +1100 (EST) From: Bruce Evans X-X-Sender: To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , Subject: Re: KSE question In-Reply-To: <3C51EC04.D99E8491@mindspring.com> Message-ID: <20020128111527.N40006-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 25 Jan 2002, Terry Lambert wrote: > The worst case scenario is: > > 1) Multithreaded program on SMP system > 2) FPU thread runs on CPU #1 and causes, but does not > reap exception > 3) Non-FPU thread runs on CPU #1 > 4) Original FPU thread resumes running on CPU #2; no > exception is correctly signalled Actually: 4) Original FPU thread resumes running on CPU #2; exception is correctly signalled (i.e., not yet). at least for non-broken i386's. For broken i386's (ones with a separate FPU or ones with a backwards bug-for-bug-compatibility mode enabled): 3a) Saving state for FPU thread causes bogus exception in the context of the non-FPU thread (actually in the context switcher if the context switcher waits a bit); context switcher knows that it is bogus and ignores it. 4a) Restoring state for FPU thread causes bogus exception in the context of the FPU thread (actually in the context switcher); context switcher knows that it is bogus but (as far as I can see) can't signal it correctly (i.e., not yet). > If there's a flaw in my reasoning, I'd be happy to have it > pointed out to me... The unreaped exception is part of the FPU state (at least on i386's). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 17:37:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id B844437B404; Sun, 27 Jan 2002 17:37:19 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020128013714.LXNZ3578.rwcrmhc52.attbi.com@peter3.wemm.org>; Mon, 28 Jan 2002 01:37:14 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0S1bEs38816; Sun, 27 Jan 2002 17:37:14 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 9915D3A9A; Sun, 27 Jan 2002 17:37:13 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Alexey Zelkin , Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() In-Reply-To: <3C549659.13EEA86C@mindspring.com> Date: Sun, 27 Jan 2002 17:37:13 -0800 From: Peter Wemm Message-Id: <20020128013713.9915D3A9A@overcee.wemm.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 Terry Lambert wrote: > Alexey Zelkin wrote: > > Heh! I'm not a linker guru, so could you please explain problem more > > deeply ? And in case if it's actually problem -- it will be fixed. > > > > It's important now since I am going to merge many locale specific changes > > to STABLE soon. And would like to have it as more clean as possible. > > /usr/src/lib/csu/i386-elf/ > > Look at how _init: is defined in crti.S, and look for > the definition of "monstartup()", and its use in crt1.c. > > Basically, this is code that gets called before any > user code. > > In Windows terms, this is where you would put "process > attach" functions for starting things like apartment > model threading for a COM/OLE component in a DLL. The > "process detach" is basically the "atexit". > > FreeBSD and Linux still don't have a "thread attach/detach", > so don't get your hopes up, if you're a Windows programmer: > there's still cool things you simply can't do. 8-). > > The G++ abuse is for the constructors. There's a linker > set called "ctor_list"; this is executed by dereferencing > the function pointer from the list (not in a particular > order... bad for C++, actually) from the function "do_ctors" > in the file /usr/src/lib/csu/common/crtbegin.c . To "abuse" > this, all you have to do is add a function to the linker > set, using an asm directive, and the function will get > called around the time the constructors are called. If you > think it's important to call your function earlier than any > constructors, this might not be the way to go. First of all, dont look at /usr/src/lib/csu/common/crtbegin.c - it is not used on FreeBSD. We use the crtstuff.c file from gcc instead when gcc is being used. On Alpha we use an alpha assembler crtstuff.asm file and the same on many of the other cpu platforms. This file is only here as a placeholder while bootstrapping new platforms. The files used instead of /usr/src/lib/csu/common/crtbegin.c are: src/contrib/gcc.295/crtstuff.c src/contrib/gcc.295/config/alpha/crtbegin.asm src/contrib/gcc.295/config/alpha/crtend.asm src/contrib/gcc/config/ia64/crtbegin.asm (gcc 3 and later) src/contrib/gcc/config/ia64/crtend.asm (gcc 3 and later) and so on. If you want to do this in a ``portable'' way (I say portable because it uses gcc extensions rather than inline asm for each platform), try this: peter@overcee[5:31pm]/tmp-122> cat cons.c void begin (void) __attribute__((__constructor__)); void end (void) __attribute__((__destructor__)); void begin(void) { write(1, "BEGIN\n", 6); } void end(void) { write(1, "END\n", 4); } int main(int ac, char **av) { printf("hello world\n"); exit(0); } peter@overcee[5:32pm]/tmp-123> cc -static -o cons cons.c peter@overcee[5:33pm]/tmp-124> ./cons BEGIN hello world END (I used -static because the destructor call happens after libc.so has become unavailable.. ie: less than useful). This works for shared objects too. If this solves the problem at hand, I'd far rather that we used this gcc extension than yet more magic inline asm (a different gcc extension). 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 Jan 27 17:46:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 233FF37B400; Sun, 27 Jan 2002 17:46:25 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020128014624.LADC10199.rwcrmhc53.attbi.com@peter3.wemm.org>; Mon, 28 Jan 2002 01:46:24 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0S1kOs38855; Sun, 27 Jan 2002 17:46:24 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 2090A3A9A; Sun, 27 Jan 2002 17:46:24 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert , Alexey Zelkin , Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() In-Reply-To: <20020128013713.9915D3A9A@overcee.wemm.org> Date: Sun, 27 Jan 2002 17:46:24 -0800 From: Peter Wemm Message-Id: <20020128014624.2090A3A9A@overcee.wemm.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 I wrote: > If this solves the problem at hand, I'd far rather that we used this gcc > extension than yet more magic inline asm (a different gcc extension). The code was a proof of concept. Before using such a thing in freebsd, we would need to do the usual magic in sys/cdefs.h along the same lines that we define __dead2, __printflike etc. 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 Jan 27 19:58:43 2002 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 83C8837B404; Sun, 27 Jan 2002 19:58:41 -0800 (PST) Received: from pool0060.cvx40-bradley.dialup.earthlink.net ([216.244.42.60] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16V2wI-0004Ki-00; Sun, 27 Jan 2002 19:58:39 -0800 Message-ID: <3C54CC61.47D078D2@mindspring.com> Date: Sun, 27 Jan 2002 19:58:25 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Alexey Zelkin , Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() References: <20020128013713.9915D3A9A@overcee.wemm.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 Peter Wemm wrote: [ ... correction ... ] [ ... example ... ] Thanks for both, Peter! THese should be captured in the handbook! > (I used -static because the destructor call happens after libc.so has become > unavailable.. ie: less than useful). > > This works for shared objects too. > > If this solves the problem at hand, I'd far rather that we used this gcc > extension than yet more magic inline asm (a different gcc extension). These should probably be in header files, so that they can be used generally. We might want to consider a "thread_begin" and "thread_end", as well, to create/destroy per thread instance data for things like libc. This would be one way of resolving the static buffer/reentrancy problem, without having to add all sorts of "_r" functions, as long as everyone was careful not to pass the resulting pointers between threads (since they would be thread local storage). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 19:59:37 2002 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 3384437B404; Sun, 27 Jan 2002 19:59:36 -0800 (PST) Received: from pool0060.cvx40-bradley.dialup.earthlink.net ([216.244.42.60] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16V2xD-0005Of-00; Sun, 27 Jan 2002 19:59:35 -0800 Message-ID: <3C54CC9A.BB1B7C60@mindspring.com> Date: Sun, 27 Jan 2002 19:59:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Alexey Zelkin , Chad David , "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() References: <20020128014624.2090A3A9A@overcee.wemm.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 Peter Wemm wrote: > > If this solves the problem at hand, I'd far rather that we used this gcc > > extension than yet more magic inline asm (a different gcc extension). > > The code was a proof of concept. Before using such a thing in freebsd, > we would need to do the usual magic in sys/cdefs.h along the same lines > that we define __dead2, __printflike etc. Yes. I'd like to see this become a general facility. THere are all sorts of interesting applications for such code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 21:56:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id A8D9E37B400; Sun, 27 Jan 2002 21:56:05 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0S5txM23509; Mon, 28 Jan 2002 08:55:59 +0300 (MSK) (envelope-from ache) Date: Mon, 28 Jan 2002 08:55:58 +0300 From: "Andrey A. Chernov" To: Chad David , phantom@FreeBSD.org Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.org Subject: Re: strtod() Message-ID: <20020128055557.GA23297@nagual.pp.ru> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127083529.GA13957@nagual.pp.ru> <20020127024626.B40668@colnta.acns.ab.ca> <20020127105258.GA14836@nagual.pp.ru> <20020127130625.A42735@colnta.acns.ab.ca> <20020127224529.GA20003@nagual.pp.ru> <20020127161626.A62332@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127161626.A62332@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i Sender: owner-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, Jan 27, 2002 at 16:16:26 -0700, Chad David wrote: > I don't understand what you mean. > This is locale code bug and EINVAL from strtol() really helps to find it. Try the patch below, it fix the problem (at least on my testing): --- lmonetary.c.old Thu Dec 13 12:26:25 2001 +++ lmonetary.c Mon Jan 28 08:50:21 2002 @@ -27,6 +27,7 @@ */ #include +#include #include "lmonetary.h" #include "ldpart.h" @@ -60,6 +61,14 @@ static int _monetary_using_locale; static char *_monetary_locale_buf; +static char +cnv(const char *str) { + int i = strtol(str, NULL, 10); + if (i == -1) + i = CHAR_MAX; + return (char)i; +} + int __monetary_load_locale(const char *name) { @@ -69,9 +78,22 @@ _monetary_locale_buf, "LC_MONETARY", LCMONETARY_SIZE, LCMONETARY_SIZE, (const char **)&_monetary_locale); - if (ret == 0 && _monetary_using_locale) + if (ret == 0 && _monetary_using_locale) { _monetary_locale.mon_grouping = __fix_locale_grouping_str(_monetary_locale.mon_grouping); + +#define M_ASSIGN_CHAR(NAME) (((char *)_monetary_locale.NAME)[0] = \ + cnv(_monetary_locale.NAME)) + + M_ASSIGN_CHAR(int_frac_digits); + M_ASSIGN_CHAR(frac_digits); + M_ASSIGN_CHAR(p_cs_precedes); + M_ASSIGN_CHAR(p_sep_by_space); + M_ASSIGN_CHAR(n_cs_precedes); + M_ASSIGN_CHAR(n_sep_by_space); + M_ASSIGN_CHAR(p_sign_posn); + M_ASSIGN_CHAR(n_sign_posn); + } return ret; } @@ -93,14 +115,14 @@ "mon_grouping = %s\n" "positive_sign = %s\n" "negative_sign = %s\n" - "int_frac_digits = %s\n" - "frac_digits = %s\n" - "p_cs_precedes = %s\n" - "p_sep_by_space = %s\n" - "n_cs_precedes = %s\n" - "n_sep_by_space = %s\n" - "p_sign_posn = %s\n" - "n_sign_posn = %s\n", + "int_frac_digits = %d\n" + "frac_digits = %d\n" + "p_cs_precedes = %d\n" + "p_sep_by_space = %d\n" + "n_cs_precedes = %d\n" + "n_sep_by_space = %d\n" + "p_sign_posn = %d\n" + "n_sign_posn = %d\n", _monetary_locale.int_curr_symbol, _monetary_locale.currency_symbol, _monetary_locale.mon_decimal_point, @@ -108,14 +130,14 @@ _monetary_locale.mon_grouping, _monetary_locale.positive_sign, _monetary_locale.negative_sign, - _monetary_locale.int_frac_digits, - _monetary_locale.frac_digits, - _monetary_locale.p_cs_precedes, - _monetary_locale.p_sep_by_space, - _monetary_locale.n_cs_precedes, - _monetary_locale.n_sep_by_space, - _monetary_locale.p_sign_posn, - _monetary_locale.n_sign_posn + _monetary_locale.int_frac_digits[0], + _monetary_locale.frac_digits[0], + _monetary_locale.p_cs_precedes[0], + _monetary_locale.p_sep_by_space[0], + _monetary_locale.n_cs_precedes[0], + _monetary_locale.n_sep_by_space[0], + _monetary_locale.p_sign_posn[0], + _monetary_locale.n_sign_posn[0] ); } #endif /* LOCALE_DEBUG */ --- localeconv.c.old Fri Dec 21 07:27:35 2001 +++ localeconv.c Mon Jan 28 08:44:47 2002 @@ -41,8 +41,6 @@ #endif /* LIBC_SCCS and not lint */ #include -#include -#include #include "lmonetary.h" #include "lnumeric.h" @@ -58,14 +56,6 @@ int __mlocale_changed = 1; int __nlocale_changed = 1; -static char -cnv(char *str) { - int i = strtol(str, NULL, 10); - if (i == -1) - i = CHAR_MAX; - return (char)i; -} - /* * Return the current locale conversion. */ @@ -79,7 +69,7 @@ struct lc_monetary_T * mptr; #define M_ASSIGN_STR(NAME) (ret.NAME = (char*)mptr->NAME) -#define M_ASSIGN_CHAR(NAME) (ret.NAME = cnv((char*)mptr->NAME)) +#define M_ASSIGN_CHAR(NAME) (ret.NAME = mptr->NAME[0]) mptr = __get_current_monetary_locale(); M_ASSIGN_STR(int_curr_symbol); -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 22:22:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 719FE37B400; Sun, 27 Jan 2002 22:22:38 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0S6MWV15952; Sun, 27 Jan 2002 23:22:32 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0S6MWs65066; Sun, 27 Jan 2002 23:22:32 -0700 (MST) (envelope-from davidc) Date: Sun, 27 Jan 2002 23:22:31 -0700 From: Chad David To: "Andrey A. Chernov" Cc: phantom@FreeBSD.org, "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.org Subject: Re: strtod() Message-ID: <20020127232231.A65050@colnta.acns.ab.ca> Mail-Followup-To: "Andrey A. Chernov" , phantom@FreeBSD.org, "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.org References: <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> <20020127003719.A38420@colnta.acns.ab.ca> <20020127083529.GA13957@nagual.pp.ru> <20020127024626.B40668@colnta.acns.ab.ca> <20020127105258.GA14836@nagual.pp.ru> <20020127130625.A42735@colnta.acns.ab.ca> <20020127224529.GA20003@nagual.pp.ru> <20020127161626.A62332@colnta.acns.ab.ca> <20020128055557.GA23297@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020128055557.GA23297@nagual.pp.ru>; from ache@nagual.pp.ru on Mon, Jan 28, 2002 at 08:55:58AM +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 On Mon, Jan 28, 2002 at 08:55:58AM +0300, Andrey A. Chernov wrote: > On Sun, Jan 27, 2002 at 16:16:26 -0700, Chad David wrote: > > > I don't understand what you mean. > > > > This is locale code bug and EINVAL from strtol() really helps to find it. > > Try the patch below, it fix the problem (at least on my testing): Yes, this works for me. Thank you. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 27 22:38:27 2002 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 9309237B400; Sun, 27 Jan 2002 22:38:21 -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 RAA23804; Mon, 28 Jan 2002 17:38:08 +1100 Date: Mon, 28 Jan 2002 17:40:02 +1100 (EST) From: Bruce Evans X-X-Sender: To: Chad David Cc: Alexey Zelkin , "Andrey A. Chernov" , "Brian F. Feldman" , Subject: Re: strtod() In-Reply-To: <20020127131125.B42735@colnta.acns.ab.ca> Message-ID: <20020128173725.W41376-100000@gamplex.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, 27 Jan 2002, Chad David wrote: > The differences between 1.3 are pretty minor though, and they do not > affect this. > > colnta->cvs diff -ud -r 1.3 localeconv.c > Index: localeconv.c > =================================================================== > RCS file: /mnt1/ncvs/src/lib/libc/locale/localeconv.c,v > retrieving revision 1.3 > retrieving revision 1.9 > diff -u -d -r1.3 -r1.9 > --- localeconv.c 10 Feb 2001 02:00:56 -0000 1.3 > +++ localeconv.c 20 Dec 2001 15:30:02 -0000 1.9 > > [cut copyright] > > @@ -29,11 +36,13 @@ > #if 0 > static char sccsid[] = "@(#)localeconv.c 8.1 (Berkeley) 6/4/93"; > #endif > -static char rcsid[] = "$FreeBSD: src/lib/libc/locale/localeconv.c,v 1.3 2001/02/10 02:00:56 ache Exp $"; > +static char rcsid[] = > + "$FreeBSD: src/lib/libc/locale/localeconv.c,v 1.9 2001/12/20 15:30:02 phantom Exp $"; > #endif /* LIBC_SCCS and not lint */ > > #include > #include > +#include > #include "lmonetary.h" > #include "lnumeric.h" > > @@ -51,7 +60,10 @@ > > static char > cnv(char *str) { > - return (char)strtol(str, NULL, 0); > + int i = strtol(str, NULL, 10); > + if (i == -1) > + i = CHAR_MAX; > + return (char)i; > } > > This change here detected that strtol() was failing, but didn't fix errno. This change actually adds 3 style bugs and a magic conversion, but doesn't detect that strtol() fails. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 28 7: 3:14 2002 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 82A7D37B489 for ; Mon, 28 Jan 2002 07:03:01 -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 g0SF0B742008 for ; Mon, 28 Jan 2002 16:00:12 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: Geom project, limited preview... From: Poul-Henning Kamp Date: Mon, 28 Jan 2002 16:00:11 +0100 Message-ID: <42006.1012230011@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok, some of you have heard that the Geom project is now finally underway. You can get a brief (and old) idea what it is here: http://www.freebsd.org/~phk/Geom General access to the source will happen when the code is "ready to do something" for the average machine, which said another way is when BSD and MBR is working well enough to boot a random -current machine, hopefully in less than a month. In the meantime I'll provide early access to people who have a qualified interest in this code. (Send me email, leave your bikeshed at home.) I will present the architecture in Geom and answer questions about it in a timeslot assigned for it at the kernel summit at BSDcon. I'm interested in getting in touch with people who are interested in writing modules for Geom or people who work new architectures and have to contest strange disklabel formats -> get in touch with me. -- 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 Mon Jan 28 9:20:47 2002 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 7008F37B416; Mon, 28 Jan 2002 09:20: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 g0SHKfo18288; Mon, 28 Jan 2002 10:20:41 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SHKex10789; Mon, 28 Jan 2002 10:20:40 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 10:19:16 -0700 (MST) Message-Id: <20020128.101916.97702861.imp@village.org> To: phk@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... From: "M. Warner Losh" In-Reply-To: <42006.1012230011@critter.freebsd.dk> References: <42006.1012230011@critter.freebsd.dk> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <42006.1012230011@critter.freebsd.dk> Poul-Henning Kamp writes: : Ok, some of you have heard that the Geom project is now finally underway. Can you characterize which devices currently are scheduled to be broken by these changes, if any. If there are some that you can't test or won't fix, knowing sooner rather than later will help people that might care about those devices. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 28 9:29:16 2002 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 ABFE137B402 for ; Mon, 28 Jan 2002 09:29:09 -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 g0SHQG744518; Mon, 28 Jan 2002 18:26:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... In-Reply-To: Your message of "Mon, 28 Jan 2002 10:19:16 MST." <20020128.101916.97702861.imp@village.org> Date: Mon, 28 Jan 2002 18:26:16 +0100 Message-ID: <44516.1012238776@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 <20020128.101916.97702861.imp@village.org>, "M. Warner Losh" writes: >In message: <42006.1012230011@critter.freebsd.dk> > Poul-Henning Kamp writes: >: Ok, some of you have heard that the Geom project is now finally underway. > >Can you characterize which devices currently are scheduled to be >broken by these changes, if any. If there are some that you can't >test or won't fix, knowing sooner rather than later will help people >that might care about those devices. Well, I plan to circumvent disk_create() disk_destroy() to Geom so all current devices should work more or less unharmed... CCD and Vinum are the greatest unknowns at this time, and how they fare depends a lot on what evilness the contain. -- 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 Mon Jan 28 10:15:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 37E8637B402; Mon, 28 Jan 2002 10:15:16 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g0SIFFg03962; Mon, 28 Jan 2002 11:15:15 -0700 (MST) (envelope-from ken) Date: Mon, 28 Jan 2002 11:15:14 -0700 From: "Kenneth D. Merry" To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... Message-ID: <20020128111514.A3819@panzer.kdm.org> References: <42006.1012230011@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <42006.1012230011@critter.freebsd.dk>; from phk@FreeBSD.ORG on Mon, Jan 28, 2002 at 04:00:11PM +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 Mon, Jan 28, 2002 at 16:00:11 +0100, Poul-Henning Kamp wrote: > > Ok, some of you have heard that the Geom project is now finally underway. > > You can get a brief (and old) idea what it is here: > > http://www.freebsd.org/~phk/Geom > > General access to the source will happen when the code is "ready to > do something" for the average machine, which said another way is > when BSD and MBR is working well enough to boot a random -current > machine, hopefully in less than a month. > > In the meantime I'll provide early access to people who have a > qualified interest in this code. (Send me email, leave your bikeshed > at home.) > > I will present the architecture in Geom and answer questions about it > in a timeslot assigned for it at the kernel summit at BSDcon. > > I'm interested in getting in touch with people who are interested in > writing modules for Geom or people who work new architectures and > have to contest strange disklabel formats -> get in touch with me. Looks interesting. If you end up doing any striping, mirroring or RAID with this, I would suggest/request you put hooks in for: - different on-disk metadata types. There is a specific project I've been working on (not for FreeBSD, unfortunately) that involves changing a software RAID implementation to have support for multiple types of on-disk metadata. - support for external parity engines for RAID-5 parity calculation. (If you do any sort of RAID-5 with this.) Another interesting thing you could do with this would be tied in with your "COW" proposal. In essence, you could create a block-level checkpoint functionality. You would have the primary device, which would continue to receive read and write requests after the checkpoint instantiation, and then the secondary device, where you would copy the original version of any sectors written to the primary device after the checkpoint. This way, you could have a device checkpoint at a given time. It would be the opposite of your "COW" proposal, in that the secondary device gets a copy of the original data, instead of any writes to the primary device. This wouldn't be as nice as the FFS checkpoint functionality, but could be useful. (With filesystem checkpoints, you can more accurately guarantee filesystem consistency, and you can make use of space unused by the filesystem. With block device checkpoints, you have to have another device for temporary storage.) (The Adaptec 'aac' raid controllers have this sort of functionality, but it is currently only available under Windows.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 28 11:16:16 2002 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 8E60C37B402 for ; Mon, 28 Jan 2002 11:16:09 -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 g0SJDF745942; Mon, 28 Jan 2002 20:13:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... In-Reply-To: Your message of "Mon, 28 Jan 2002 11:15:14 MST." <20020128111514.A3819@panzer.kdm.org> Date: Mon, 28 Jan 2002 20:13:15 +0100 Message-ID: <45940.1012245195@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 <20020128111514.A3819@panzer.kdm.org>, "Kenneth D. Merry" writes: >Looks interesting. > >If you end up doing any striping, mirroring or RAID with this, I would >suggest/request you put hooks in for: > > - different on-disk metadata types. There is a specific project I've been > working on (not for FreeBSD, unfortunately) that involves changing a > software RAID implementation to have support for multiple types of on-disk > metadata. My plan was to recognize what I can, and have a way for userland to configure as well. > - support for external parity engines for RAID-5 parity calculation. (If > you do any sort of RAID-5 with this.) Well, I have no raid-5 hardware so this would probably have to be left to somebody else. >Another interesting thing you could do with this would be tied in with your >"COW" proposal. In essence, you could create a block-level checkpoint >functionality. You would have the primary device, which would continue to >receive read and write requests after the checkpoint instantiation, and >then the secondary device, where you would copy the original version of any >sectors written to the primary device after the checkpoint. Hmm, that is the reverse of what I thought it should do, but I can certainly see the point... -- 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 Mon Jan 28 12:18:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id B2CD237B402 for ; Mon, 28 Jan 2002 12:18:44 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g0SKIYp05145; Mon, 28 Jan 2002 13:18:34 -0700 (MST) (envelope-from ken) Date: Mon, 28 Jan 2002 13:18:34 -0700 From: "Kenneth D. Merry" To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... Message-ID: <20020128131834.A4983@panzer.kdm.org> References: <20020128111514.A3819@panzer.kdm.org> <45940.1012245195@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <45940.1012245195@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Jan 28, 2002 at 08:13:15PM +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 Mon, Jan 28, 2002 at 20:13:15 +0100, Poul-Henning Kamp wrote: > In message <20020128111514.A3819@panzer.kdm.org>, "Kenneth D. Merry" writes: > > >Looks interesting. > > > >If you end up doing any striping, mirroring or RAID with this, I would > >suggest/request you put hooks in for: > > > > - different on-disk metadata types. There is a specific project I've been > > working on (not for FreeBSD, unfortunately) that involves changing a > > software RAID implementation to have support for multiple types of on-disk > > metadata. > > My plan was to recognize what I can, and have a way for userland to configure > as well. The main thing is that you design the metadata handling code so that additional metadata types can be added later without too much trouble. This will require thought, especially for multilevel array types. e.g., I know of two different Adaptec metadata types that handle multilevel arrays in different ways. With the first, everything is spelled out in one chunk of metadata at the end of each physical disk. If you've got a RAID-10, it defines the RAID-1 arrays and the RAID-0 stripe set over the RAID-1 arrays. With the second, each level is defined by metadata at the beginning of the component piece. So with a RAID-10, the physical disk would have information about the RAID-1 array at the beginning. The RAID-1 array would have information about the RAID-0 array at the beginning. Depending on your design, it may be easier to deal with one type of multilevel metadata than another. The key is to remember that both exist, and may need to be supported at some point. So you want to design your metadata handling code and your array autoconfiguration code so that you can deal with either arrangement. > > - support for external parity engines for RAID-5 parity calculation. (If > > you do any sort of RAID-5 with this.) > > Well, I have no raid-5 hardware so this would probably have to be left > to somebody else. I only requested "hooks", not actual support. :) Adaptec makes some boards, the AAA series, that would be able to use software RAID with hooks for an external parity engine. They haven't made any new designs with that architecture since the Ultra-2 days, though. You'll probably also want to put in hooks for choosing the fastest parity calculation routine for a given machine. (Since you may want to write assembly versions for MMX, SSE, etc., capable processors.) > >Another interesting thing you could do with this would be tied in with your > >"COW" proposal. In essence, you could create a block-level checkpoint > >functionality. You would have the primary device, which would continue to > >receive read and write requests after the checkpoint instantiation, and > >then the secondary device, where you would copy the original version of any > >sectors written to the primary device after the checkpoint. > > Hmm, that is the reverse of what I thought it should do, but I can > certainly see the point... I think doing it either way would be useful. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 28 12:42:39 2002 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 297DC37B400 for ; Mon, 28 Jan 2002 12:42:32 -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 g0SKdd747068; Mon, 28 Jan 2002 21:39:40 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... In-Reply-To: Your message of "Mon, 28 Jan 2002 13:18:34 MST." <20020128131834.A4983@panzer.kdm.org> Date: Mon, 28 Jan 2002 21:39:39 +0100 Message-ID: <47066.1012250379@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 <20020128131834.A4983@panzer.kdm.org>, "Kenneth D. Merry" writes: [...] >This will require thought, [...] >[...] >Depending on your design, [...] I am sure you are right, but I cannot really provide you any assurance as to what can and what cannot be done yet. Between you and sos@ and me, I am sure we can cover this ground, but I have this nagging feeling that a geom module of the kind we are talking about, is composed of 10% "doing the actual I/O" and 90% "dissecting the on-disk configuration records and setting things up". I have implemented some generic code for your average "subdisk" module (BSD, MBR, SUNLABEL, MACLABEL and so on) but the actual savings is surprisingly small (the benefit in consistency is of course still more than enough to justify it). I _think_ my design and code allows for "doing anything" but I may be wrong. -- 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 Mon Jan 28 15:40:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 454A737B402 for ; Mon, 28 Jan 2002 15:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020128234009.SDLN3578.rwcrmhc52.attbi.com@InterJet.elischer.org> for ; Mon, 28 Jan 2002 23:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA48240 for ; Mon, 28 Jan 2002 15:33:45 -0800 (PST) Date: Mon, 28 Jan 2002 15:33:44 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: KSE milestone 3 reached. 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 In October or so I stated that Milestone 3 would be when a test program could run several threads concurrently doing system calls (on one processor at the moment). I have reached that point however I need to 'back-fill' with the help of others to fix things that I seem to have broken, for example I think I've broken gdb's ability to control procrsses. Anyhow, The following program, when linked with a small library (not supplied) yeilds the following expected result: A non-library version of this program is available with the patches at http://www.freebsd.org/~julian. program: #include #include #include /************************************************************* * code for three separate threads. (so we can see if it works) *************************************************************/ static void thread1_code(void *arg) { for(;;) { sleep (1); write(1,".",1); } } static void thread2_code(void *arg) { for(;;) { sleep (3); write(1,"+",1); } } static void thread3_code(void *arg) { for(;;) { sleep (5); write(1,"=",1); } } int main() { /* set up global structures */ TAILQ_INIT(&runqueue); /* define two threads to run, they are runnable but not yet running */ make_bg_thread(&thread1_code, 0, NULL); make_bg_thread(&thread2_code, 0, NULL); /* start two KSEs in different KSEGRPs */ if (startkse(&first_kse)) { perror("failed to start KSE"); exit(1); } /* and one which we will run ourself */ makemainthread(&thread3_code, 0, NULL); thread3_code(NULL); return 0; } A more convenient interface would be easy to figure out.. this is just for debugging.. result: (line wrap added by me) # /ksetest/ksetest ..+..=.+...+.=..+...=+...+..=.+...+.=..+...=+...+..=.+...+.=..+...=+...+..= .+...+.=..+...=+...+..=.+...+.=^C#D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 29 1:26:48 2002 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 BE19237B417 for ; Tue, 29 Jan 2002 01:26:45 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16VUZy-0005UH-00; Tue, 29 Jan 2002 11:29:26 +0200 From: Sheldon Hearn To: Julian Elischer Cc: arch@freebsd.org Subject: Re: KSE milestone 3 reached. In-reply-to: Your message of "Mon, 28 Jan 2002 15:33:44 PST." Date: Tue, 29 Jan 2002 11:29:26 +0200 Message-ID: <21096.1012296566@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 Mon, 28 Jan 2002 15:33:44 PST, Julian Elischer wrote: > I have reached that point however I need to 'back-fill' with the help of > others to fix things that I seem to have broken, for example > I think I've broken gdb's ability to control procrsses. As an aside, if your search for gdb maintainers bears fruit, please let me know. The rest of the PR workers and I would very much like to know who to assign all Kip Macy's PRs to. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 29 11:22:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id A897F37B417 for ; Tue, 29 Jan 2002 11:22:16 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.11.3/8.10.1) with ESMTP id g0TJMaE50607; Tue, 29 Jan 2002 11:22:38 -0800 (PST) Date: Tue, 29 Jan 2002 11:22:36 -0800 (PST) From: Doug White To: Sheldon Hearn Cc: Julian Elischer , Subject: Re: KSE milestone 3 reached. In-Reply-To: <21096.1012296566@axl.seasidesoftware.co.za> Message-ID: <20020129112202.D48817-100000@resnet.uoregon.edu> X-All-Your-Base: are belong to us 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, 29 Jan 2002, Sheldon Hearn wrote: > As an aside, if your search for gdb maintainers bears fruit, please let > me know. The rest of the PR workers and I would very much like to know > who to assign all Kip Macy's PRs to. :-) Apparently my attempts to trick Kip Macy into taking over gdb maintainership have yet to ripen. :) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | 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 Jan 29 11:40:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 29CBA37B402 for ; Tue, 29 Jan 2002 11:40:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020129194008.UZVQ10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 29 Jan 2002 19:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA52328; Tue, 29 Jan 2002 11:34:25 -0800 (PST) Date: Tue, 29 Jan 2002 11:34:24 -0800 (PST) From: Julian Elischer To: Doug White Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. In-Reply-To: <20020129112202.D48817-100000@resnet.uoregon.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 I'm not actually looking for a gdb maintainer, so much as someone who understands teh KERNEL side of how gdb controls a process. And anyhow, didn't Mark Peek volunteer to take on gdb? Julian On Tue, 29 Jan 2002, Doug White wrote: > On Tue, 29 Jan 2002, Sheldon Hearn wrote: > > > As an aside, if your search for gdb maintainers bears fruit, please let > > me know. The rest of the PR workers and I would very much like to know > > who to assign all Kip Macy's PRs to. :-) > > Apparently my attempts to trick Kip Macy into taking over gdb > maintainership have yet to ripen. :) > > Doug White | FreeBSD: The Power to Serve > dwhite@resnet.uoregon.edu | 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 Tue Jan 29 12: 7:41 2002 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 CA92F37B405 for ; Tue, 29 Jan 2002 12:07:38 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0TK7Na81722; Tue, 29 Jan 2002 12:07:23 -0800 (PST) (envelope-from obrien) Date: Tue, 29 Jan 2002 12:07:23 -0800 From: "David O'Brien" To: Doug White Cc: Sheldon Hearn , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. Message-ID: <20020129120723.A81682@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <21096.1012296566@axl.seasidesoftware.co.za> <20020129112202.D48817-100000@resnet.uoregon.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020129112202.D48817-100000@resnet.uoregon.edu>; from dwhite@resnet.uoregon.edu on Tue, Jan 29, 2002 at 11:22:36AM -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, Jan 29, 2002 at 11:22:36AM -0800, Doug White wrote: > On Tue, 29 Jan 2002, Sheldon Hearn wrote: > > > As an aside, if your search for gdb maintainers bears fruit, please let > > me know. The rest of the PR workers and I would very much like to know > > who to assign all Kip Macy's PRs to. :-) > > Apparently my attempts to trick Kip Macy into taking over gdb > maintainership have yet to ripen. :) I thought we also had roped Mark Peek into that job. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 29 13:20:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 7B16437B417; Tue, 29 Jan 2002 13:20:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020129212018.XXZV10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 29 Jan 2002 21:20:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA52703; Tue, 29 Jan 2002 13:17:29 -0800 (PST) Date: Tue, 29 Jan 2002 13:17:26 -0800 (PST) From: Julian Elischer To: "David O'Brien" Cc: Doug White , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. In-Reply-To: <20020129120723.A81682@dragon.nuxi.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 While we are on similare topics. any chance that the stack-frame-size options are in gcc 3.x? if not, any chance we can get it in.. I have 3 versions for 2.95.. On Tue, 29 Jan 2002, David O'Brien wrote: > On Tue, Jan 29, 2002 at 11:22:36AM -0800, Doug White wrote: > > On Tue, 29 Jan 2002, Sheldon Hearn wrote: > > > > > As an aside, if your search for gdb maintainers bears fruit, please let > > > me know. The rest of the PR workers and I would very much like to know > > > who to assign all Kip Macy's PRs to. :-) > > > > Apparently my attempts to trick Kip Macy into taking over gdb > > maintainership have yet to ripen. :) > > I thought we also had roped Mark Peek into that job. :-) > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 29 20:15:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id 2A17937B992 for ; Tue, 29 Jan 2002 20:15:30 -0800 (PST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g0U4FT724814 for ; Tue, 29 Jan 2002 20:15:29 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 29 Jan 2002 20:15:29 -0800 Received: from build12 (build12.apple.com [17.202.14.95]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g0U4FTw06066 for ; Tue, 29 Jan 2002 20:15:29 -0800 (PST) Date: Tue, 29 Jan 2002 20:15:27 -0800 Mime-Version: 1.0 (Apple Message framework v502) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: __P macro question From: Dallas De Atley To: arch@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.502) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I asked a question of our resident experts here at Apple and was eventually directed to you by Jordan Hubbard. My question was: What is the __P macro used for in all those function declarations in the BSD libraries and do we still need it? It was explained that this macro is used for pre-ANSI C compilers and that while Darwin and thus Mac OS X compile with gcc 2.95, we retain it in our code so that the diffs between our code and yours is small. This enables the Darwin team to keep on top of changes between FreeBSD and Darwin. After doing a little bit of homework searching cdef.h and style.9 and encountering old jokes concerning the coming of Jesus (thank you Google), I decided to pursue the question. Is the __P macro still necessary? Are there pre ANSI C compilers FreeBSD wishes to support or is this macro effectively benign but useless? If it is still neccesary I'll move on to bothering the resident experts with other annoying questions, otherwise I'd like to pursue this issue further. Thanks, Dallas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 29 23:37:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id CDEF737B404 for ; Tue, 29 Jan 2002 23:37:26 -0800 (PST) Received: from elischer.org ([64.164.10.134]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQQ005OKQIE60@mta6.snfc21.pbi.net> for arch@freebsd.org; Tue, 29 Jan 2002 23:37:26 -0800 (PST) Date: Tue, 29 Jan 2002 23:37:26 -0800 From: Julian Elischer Subject: Re: __P macro question To: Dallas De Atley Cc: arch@freebsd.org Message-id: <3C57A2B6.381884D8@elischer.org> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Accept-Language: en, hu References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dallas De Atley wrote: > > Hi, > > I asked a question of our resident experts here at Apple and was > eventually directed to you by Jordan Hubbard. > > My question was: What is the __P macro used for in all those > function declarations in the BSD libraries and do we still need it? > > It was explained that this macro is used for pre-ANSI C compilers > and that while Darwin and thus Mac OS X compile with gcc 2.95, we retain > it in our code so that the diffs between our code and yours is small. > This enables the Darwin team to keep on top of changes between FreeBSD > and Darwin. > > After doing a little bit of homework searching cdef.h and style.9 > and encountering old jokes concerning the coming of Jesus (thank you > Google), I decided to pursue the question. > > Is the __P macro still necessary? Are there pre ANSI C compilers > FreeBSD wishes to support or is this macro effectively benign but > useless? > > If it is still neccesary I'll move on to bothering the resident > experts with other annoying questions, otherwise I'd like to pursue this > issue further. No it's not neccessary though some people will claim it is.. (they still have dreams of porting FreeBSD to the sinclair zx81 and fear that the only compiler they can find will not be Ansi...) (etc) I and most other committers are removing _P() from any prototypes we come into close proximity to, but the general rule of not making edits just for cosmetic purposes has stopped anyone from just removing them all, (though it is very tempting). Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 29 23:42: 2 2002 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 589D337B405; Tue, 29 Jan 2002 23:42:00 -0800 (PST) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g0U7fx630975; Tue, 29 Jan 2002 23:41:59 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.6) id g0U7gPL01072; Tue, 29 Jan 2002 23:42:25 -0800 (PST) (envelope-from marcel) Date: Tue, 29 Jan 2002 23:42:25 -0800 From: Marcel Moolenaar To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... Message-ID: <20020129234225.A981@dhcp01.pn.xcllnt.net> References: <42006.1012230011@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42006.1012230011@critter.freebsd.dk> 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, Jan 28, 2002 at 04:00:11PM +0100, Poul-Henning Kamp wrote: > > I'm interested in getting in touch with people who are interested in > writing modules for Geom or people who work new architectures and > have to contest strange disklabel formats -> get in touch with me. It looks to me that the EFI GUID Partition Table (GPT) can be dealt with almost trivially with Geom. This would be a good thing for the ia64 port and upcoming EFI based ia32 systems (if any). BTW, the documented discovery order under EFI is 1) GPT, 2) ISO-9660 and 3) Legacy MBR. This would imply that self-discovery as you suggest for MBR and BSD would have some constraints, whether it's one we hardcode or provide through a more dynamic mechanism. -- 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 Jan 29 23:53:51 2002 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 B5A8F37B400 for ; Tue, 29 Jan 2002 23:53:47 -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 g0U7ojr19202; Wed, 30 Jan 2002 08:50:50 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... In-Reply-To: Your message of "Tue, 29 Jan 2002 23:42:25 PST." <20020129234225.A981@dhcp01.pn.xcllnt.net> Date: Wed, 30 Jan 2002 08:50:45 +0100 Message-ID: <19200.1012377045@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 <20020129234225.A981@dhcp01.pn.xcllnt.net>, Marcel Moolenaar writes: >On Mon, Jan 28, 2002 at 04:00:11PM +0100, Poul-Henning Kamp wrote: >> >> I'm interested in getting in touch with people who are interested in >> writing modules for Geom or people who work new architectures and >> have to contest strange disklabel formats -> get in touch with me. > >It looks to me that the EFI GUID Partition Table (GPT) can be dealt >with almost trivially with Geom. This would be a good thing for the >ia64 port and upcoming EFI based ia32 systems (if any). Peter already mentioned this to me. >BTW, the documented discovery order under EFI is 1) GPT, 2) ISO-9660 >and 3) Legacy MBR. This would imply that self-discovery as you >suggest for MBR and BSD would have some constraints, whether it's >one we hardcode or provide through a more dynamic mechanism. I have not implemented this yet: my idea was that each method would have a hardcoded priority number and that they would get a chance to bite in priority order, that should be suffice for this. Needless to say, the "taste" routine is able to examine the local surroundings in detail, so for instance we can make the MBR look if GPT already found this particular node and if so just give 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 Jan 30 0: 4:42 2002 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 C615237B400 for ; Wed, 30 Jan 2002 00:04:35 -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 g0U84Yo28210; Wed, 30 Jan 2002 01:04:34 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0U84Xx22551; Wed, 30 Jan 2002 01:04:33 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 01:04:16 -0700 (MST) Message-Id: <20020130.010416.109979400.imp@village.org> To: deatley@apple.com Cc: arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Dallas De Atley writes: : My question was: What is the __P macro used for in all those : function declarations in the BSD libraries and do we still need it? It is there for K&R support for the most part. Although there may be some sneaky uses of it that may make it a little difficult to blindly remove. : Is the __P macro still necessary? No. : Are there pre ANSI C compilers : FreeBSD wishes to support or is this macro effectively benign but : useless? Not really. There are a few in the FreeBSD community that would like to continue to support this. However, even they admit that removing uses of the __P macro in the tree would be a good thing. However, there are several caveats: 1) Wholesale removal of this macro would likely cause merge conflicts to those using the p4 repository and who are otherwise maintaining separate projects. Since these are the cool new projects, it is widely believed that some level of coordination is needed with these products. This is especially true in the kernel. 2) There are style(9) concerns about naive removal methods, and a few other asthetic considerations as well. 3) There are concerns about how easy/hard it will be to merge changes after we do this to prior branches. The last time this came up in any real way, the folks with the pitchforks and pitch-oil that wanted to get rid of the thing were placated by the promise that it would be done as part of the glide path to the 5.0 release. I'm not sure which side of the release it will be done on, but I think the thought was before the 5.x-stable branch is created so that while we're working on 6.0 we can MFC changes to the 5.x-branch. This makes it hard on the 4.x branch, but less hard than if we had to do both 5.x and 4.x __P twingling. But I'm not sure that there is an appointed executioner, or an exact timetable for this change to take place. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 0:19:18 2002 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 DAF7C37B400 for ; Wed, 30 Jan 2002 00:19:15 -0800 (PST) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g0U8JF631048; Wed, 30 Jan 2002 00:19:15 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.6) id g0U8Jfo01173; Wed, 30 Jan 2002 00:19:41 -0800 (PST) (envelope-from marcel) Date: Wed, 30 Jan 2002 00:19:41 -0800 From: Marcel Moolenaar To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... Message-ID: <20020130001941.A1101@dhcp01.pn.xcllnt.net> References: <20020129234225.A981@dhcp01.pn.xcllnt.net> <19200.1012377045@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19200.1012377045@critter.freebsd.dk> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 30, 2002 at 08:50:45AM +0100, Poul-Henning Kamp wrote: > > I have not implemented this yet: my idea was that each method would > have a hardcoded priority number and that they would get a chance > to bite in priority order, that should be suffice for this. Agreed. > Needless to say, the "taste" routine is able to examine the local > surroundings in detail, so for instance we can make the MBR look if > GPT already found this particular node and if so just give up. Hmmm... context sensitivity always messes up a good, clean design. Maybe a "bite and swallow" approach would be acceptable: Any medium that has a detected partitioning is blocked from further examination? In don't know to what extend this would work for nested partitions within Geom (if it would work at all)... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 0:29:52 2002 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 C947637B400 for ; Wed, 30 Jan 2002 00:29:47 -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 g0U8Qpr19724; Wed, 30 Jan 2002 09:26:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... In-Reply-To: Your message of "Wed, 30 Jan 2002 00:19:41 PST." <20020130001941.A1101@dhcp01.pn.xcllnt.net> Date: Wed, 30 Jan 2002 09:26:51 +0100 Message-ID: <19722.1012379211@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 <20020130001941.A1101@dhcp01.pn.xcllnt.net>, Marcel Moolenaar writes : >> Needless to say, the "taste" routine is able to examine the local >> surroundings in detail, so for instance we can make the MBR look if >> GPT already found this particular node and if so just give up. > >Hmmm... context sensitivity always messes up a good, clean design. >Maybe a "bite and swallow" approach would be acceptable: Any medium >that has a detected partitioning is blocked from further examination? >In don't know to what extend this would work for nested partitions >within Geom (if it would work at all)... Geom is designed on the "FreeBSD: tools, not policies" dogma so that decision is made inside the individual methods, not in the framework around them. I think that for disk-partitioning the DWIM/POLA principle should prevail. Considering life as it is, it is probably too early to decide exactly how we do that, I expect us to change our mind a few times even when we do make it 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 Jan 30 0:56:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id B179937B402 for ; Wed, 30 Jan 2002 00:56:10 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16VqXA-0000RJ-00; Wed, 30 Jan 2002 00:56:01 -0800 Message-ID: <3C57B51B.F38D1906@mindspring.com> Date: Wed, 30 Jan 2002 00:55:55 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dallas De Atley Cc: arch@freebsd.org Subject: Re: __P macro question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dallas De Atley wrote: > My question was: What is the __P macro used for in all those > function declarations in the BSD libraries and do we still need it? > > It was explained that this macro is used for pre-ANSI C compilers > and that while Darwin and thus Mac OS X compile with gcc 2.95, we retain > it in our code so that the diffs between our code and yours is small. > This enables the Darwin team to keep on top of changes between FreeBSD > and Darwin. [ ... ] > Is the __P macro still necessary? Are there pre ANSI C compilers > FreeBSD wishes to support or is this macro effectively benign but > useless? > > If it is still neccesary I'll move on to bothering the resident > experts with other annoying questions, otherwise I'd like to pursue this > issue further. The first thing to note is that, unlike Linux, FreeBSD is an entire UNIX-alike system, which means that it includes a huge amount of code, not necessarily just kernel code, and the protability of that code depends on the headers, as well. For example, if I wanted to replace libc on my Altos Xenix system, it's possible for me to do so with the macros there (the Altos supplied compiler is non-ANSI, and has the side benefit of being able to generate code that runs on about 16 different platforms, unlike the SCO Xenix compiler, the Microport UNIX compiler, the Oregon compiler, etc., etc., including GCC, which would require multiple SKUs, one per platform, were it used to generate the program images). Current policy is to not add the macro to new code, but to not remove it on old code, in order to minimize gratuitous changes to the source tree. At one point in time, FreeBSD was x86 only, and 386BSD very early on discarded the Net/2 multiple platform/architecture source tree layout. This is generally recognized as a mistake these days (now that every *BSD *except* 386BSD is multiple platform/architecture), so minimizing gratuitous differences is considered an important project objective, allowing easy movement of source code between the *BSD systems. Not everyone agrees with the complete conversion to code that can only be compiled with an ANSI C compiler; I don't, and several other conservative *BSD people from way back like the idea that the code will compile with an old K&R standard compiler. Another argument (a good one, I think) is that, as the *BSD code is intended as a reference implementation from which technology may be excerpted, increasing the barrier to entry by requiring an ANSI C compiler increases the probability that a company would write its own code, which would then fail to interoperate correctly. We can see an example of this in a recent thread on the -hackers list, in which a programmer wrote a telnet client from scratch, and did not realize that the option negotiation sequence order was used by the telnet to identify older TCP/IP stacks to the server in order that clients on such systems could interoperate correctly with servers running a newer stack; if the telnet code itself had not been so opaque with all sorts of "magic" security code, the author could have used it as a starting pointm and the problem would not have occurred in the first place. Whether this is because we wish to take code and run it on an older UNIX or UNIX-like system (e.g. SVR3.2, Altos Xenix, Ultrix 4.2, Unice on VMS, etc.), or because we feel that bootstrapping on an older architecture will probably use the native compiler, which may be a K&R compiler, is less relevent than overall portability, though there are portability and interoperability issues as well (as noted above). One real problem, at least from my perspective, is that I don't want to have to port GCC, and then be its maintainer for two years (in order to comply with the distribution requirements of the GCC), should I wish to port FreeBSD to an older system, or an embedded system where there is not already a GCC port, backe end code generator, or both. It is unlikely that the modifications to the compiler needed to support such a platform would be rolled into the GCC distribution proper, which makes you liable for two years of distribution of the code, following any minor compiler modification. This doesn't even take into account the cost of porting both the compiler and the OS, instead of merely the OS. A company, once in this position, ends up having to set up a trust to maintain source availability, should they fail and go out of business ("Who ever heard of a startup failing?"). Another problem is that moving to code that compiles only with an ANSI compiler has a tendency to increase reliance on GCC-specific constructs. Right now, there are several GCC-isms in the code, and they will only be encouraged to spread by making the code GCC-compliant (as opposed to merely ANSI-compliant). Some of these are: 1) auto array declaration with a variable element size, as in: foo( int n) { int myarray[ n]; } This is legal in GCC, but not legal in ANSI-C, and is used in at least one place that I know of in FreeBSD, making it written in GCC-C, not ANSI-C. 2) Use of inline asm(), rather than seperation of source files into machine dependent and independent parts; while this is getting better, there's a lot of code in /sys/i386/*.c that should probably be shared, instead of repeated on a platform basis. 3) Use of __attribute() tags. These are used for the so-called "dead" code attribute, and also for the identification of "printf-like" functions -- the varradic functions that take format identifiers and require that there be a format element per argument in the remaining argument list following the format specifier. Some of these are warapped with "#ifdef" for GCC specificity, but most are not. Other use of this tag would be better handled through the use of "#pragma", as in "#pragma pack(1)" for structure packing for direct mapping of hardware registers; this is complicated by architectures with strict alignment requirements for objects a multiple of a byte in length (e.g. Alpha or 486 and up, with the alignment flag set in the CPU control word). 4) Use of linker sets. Most of these are wrapped; I have to admit that it was my introduction of the "SYSINIT" mechanism that really made these a pain to live without. However, compilers capable of handling C++ can handle this as well, and it's also possible to deal with this less graciously: my originally submitted SYSINIT() code could handle this by the SYSINIT()'s being sed'ed out, and a ".c" file generated to manually create a statically linked object file containing what would have been in the linker set, had linker sets been available. Personally, I'd really like to see the code stay portable, and where it's not, abstract the portability problems out, as time goes on -- not add to them by orphaning environments where reference implementations are sometimes in fact the most useful. I'd also like to see the system able to compile self-hosting on the Alpha with the Compaq compiler (a *significantly* better compiler than the GCC compiler on Alpha, particularly with the introduction of GCC 3.x, which so far produces broken Alpha code, and the most recent binutils import, which also causes problems on the Alpha, which currently can not even make it successfully through a "make world"). I rather expect that, even if there is not sufficient interest (and, honestly, the compiler doesn't generate as nice code) in getting FreeBSD capable of self-hosting with the TenDRA compiler system, getting a good (read: "commercial") Alpha or SPARC compiler able to self-host FreeBSD would be a good thing in most people's books. The Intel notes on compiling code for the Pentium 4 processor read more like a "don't do what GCC does!" criticism, than release notes. There has also been rumors that Intel would release the IA64 and even Pentium 4 (and perhaps earlier) versions of their compiler un some form of Open Source license... perhaps even as the GCC code generator for Intel systems, getting it adopted by GCC. There are a number of sound commercial reasons for doing this, in particular, if you control the compiler technology for the compiler that people grab off the net in order to benchmark hardware, this could not but help make your hardware look better than anyone elses; it remains to be seen if this rumor is true, but if it is, then it would be nice if FreeBSD were capable of being compiled with the compiler when it became available, instead of 8-10 months down the road. PS: Given that you represent Apple, which has a strong commitment to the Motorolla PowerPC architecture, you might want to put a bug in someone's ear about considering doing the same for a Motorolla or IBM originated PPC compiler, which will certainly outperform GCC's PPC code generator on that platform as well. PPS: If anyone from Sun is reading this... same for SPARC. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 1:21: 2 2002 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 2C86837B435 for ; Wed, 30 Jan 2002 01:20:47 -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 g0U9K8d64976; Wed, 30 Jan 2002 01:20:08 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Terry Lambert Cc: Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Message from Terry Lambert of "Wed, 30 Jan 2002 00:55:55 PST." <3C57B51B.F38D1906@mindspring.com> Date: Wed, 30 Jan 2002 01:20:08 -0800 Message-ID: <64972.1012382408@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 Ye flippin' gods! My hat is off to you, Terry. You've managed to effectively segue from the question of using __P() macros to hide ANSI C function declarations to a debate on the wisdom of using GCC extentions and whether or not to open-source various other types of compiler technology. It's no wonder the __P() stuff is still there if just pulling on a little string brings a truck rolling toward you. :-) I think writing portable C code as a general practice is an entirely tangental subject and one probably worthy of an entire series of encyclopedic volumes on the topic. To focus on this one *specific* issue in -arch, however, I think the debate needs to confine itself for the moment to one point and one point only: Is the set of C compilers which FreeBSD, or any directly-derived variant thereof, is likely to encounter in real life going to include one which does not grok the more modern, non-GCC specific language constructs (reminder: function prototypes) which were oh-so-long-ago approved by the ANSI committee? If the answer is "no", and I think it quite reasonably might be, then we can move forward with at least one assumption and that's that __P() can die in FreeBSD as something which merely obfuscates and renders our code more unpleasant to the eye. The old "reference" code will certainly live on in Net/1, Net/2 and all the ancient Unix code which Caldera was so recently kind enough to release back to the public and anyone needing "reference bits" for ancient hardwawre is probably not going to be well-served by FreeBSD anyway. As you point out, FreeBSD has trod the Path of Evil in the form of using gcc extentions to quite an extent and to worry about __P() or even assume that any measurable incremental value can truly be afforded by keeping it around is just silly, like spraying Lysol on a cow patty. If you want my vote, and you get it whether that's the case or not, I say we nuke __P() from orbit until it and the unlucky disk platters it formerly rested on are reduced to a molten, bubbly, radioactive slag with the merest hint of ferrous particles still coating the surface. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 1:37:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 4145637B402 for ; Wed, 30 Jan 2002 01:37:34 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16VrBK-0005nW-00; Wed, 30 Jan 2002 01:37:30 -0800 Message-ID: <3C57BED2.E1144F41@mindspring.com> Date: Wed, 30 Jan 2002 01:37:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jordan Hubbard Cc: Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <64972.1012382408@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: > I think writing portable C code as a general practice is an entirely > tangental subject and one probably worthy of an entire series of > encyclopedic volumes on the topic. To focus on this one *specific* > issue in -arch, however, I think the debate needs to confine itself > for the moment to one point and one point only: Is the set of C > compilers which FreeBSD, or any directly-derived variant thereof, is > likely to encounter in real life going to include one which does not > grok the more modern, non-GCC specific language constructs (reminder: > function prototypes) which were oh-so-long-ago approved by the ANSI > committee? You mean like when I compile "grep" and other command line tools on my Amiga using Manx Aztec C, a K&R compiler? Or when I use Watcom to take some FreeBSD code for a POS system to do the same thing for DR-DOS, because GCC won't run there because it can't be compiled to use overlays? Really, if someone can't understand __P(), they should probably not be in the kernel, with all those "dangerous" linker sets and other less obvious code than __P()... > If the answer is "no", and I think it quite reasonably might be, then > we can move forward with at least one assumption and that's that __P() > can die in FreeBSD as something which merely obfuscates and renders > our code more unpleasant to the eye. I think that portability of code between FreeBSD and OpenBSD and NetBSD is a concern, and I think increasing the diffs gratuitously between these systems is a Bad Idea(tm). Also, as has already been raised, there is an issue of doing back-ports of the code to FreeBSD X.Y, where X.Y is and of the versions prior to the cosmetic make-over. When NetBSD or OpenBSD gets new code (e.g. the SYN cache code or the ipfilter license-inspired replacement), it would be nice if porting the code would not require a human going through and deciding which differences are there because they need to be there, and which ones are there because of gratuitous cosmetic changes. > If you want my vote, and you get it whether that's the case or not, I > say we nuke __P() from orbit until it and the unlucky disk platters it > formerly rested on are reduced to a molten, bubbly, radioactive slag > with the merest hint of ferrous particles still coating the surface. Can you get BSDI, NetBSD, and OpenBSD to go along with this? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 1:44: 8 2002 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 0357537B417 for ; Wed, 30 Jan 2002 01:44:05 -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 g0U9f1r21005; Wed, 30 Jan 2002 10:41:01 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Your message of "Wed, 30 Jan 2002 01:37:22 PST." <3C57BED2.E1144F41@mindspring.com> Date: Wed, 30 Jan 2002 10:41:01 +0100 Message-ID: <21003.1012383661@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 <3C57BED2.E1144F41@mindspring.com>, Terry Lambert writes: >You mean like when I compile "grep" and other command line tools >on my Amiga using Manx Aztec C, a K&R compiler? > >Or when I use Watcom to take some FreeBSD code for a POS system >to do the same thing for DR-DOS, because GCC won't run there >because it can't be compiled to use overlays? Terry, Let me get this straight: Those two examples above are pulled from the set called "Terrys problems". The set called "The FreeBSD projects problems" has emperically been shown to not overlap "Terrys problems" to any significant degree. Plenty of innocent electrons have been wasted in the last 10 years trying to prove that that the set "Terrys problems", is the most important subset of the set "The FreeBSD projects problems", but so far no evidence has been found to support this claim. In fact, considering the amount of evidence to the contrary, most of the people involved tend to think that "Terrys problems" is very descriptive of the reason those electrons were wasted. Bugger off with your FUD will ya ? -- 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 Jan 30 1:52:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 166A837B402 for ; Wed, 30 Jan 2002 01:52:47 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16VrPw-0004LM-00; Wed, 30 Jan 2002 01:52:36 -0800 Message-ID: <3C57C25C.4C1EB64D@mindspring.com> Date: Wed, 30 Jan 2002 01:52:28 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <21003.1012383661@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > Let me get this straight: Those two examples above are pulled from > the set called "Terrys problems". > > The set called "The FreeBSD projects problems" has emperically been > shown to not overlap "Terrys problems" to any significant degree. > > Plenty of innocent electrons have been wasted in the last 10 years > trying to prove that that the set "Terrys problems", is the most > important subset of the set "The FreeBSD projects problems", but > so far no evidence has been found to support this claim. > > In fact, considering the amount of evidence to the contrary, most > of the people involved tend to think that "Terrys problems" is > very descriptive of the reason those electrons were wasted. > > Bugger off with your FUD will ya ? Poul, let me get this straight: people who use FreeBSD code for uses other than what you personally use it for, and people who take subsets of that code instead of taking the code on an all or nothing basis like you appear to want can "Bugger off"? PS: "Terry's set of problems" includes being able to diff FreeBSD code and NetBSD and OpenBSD code, as well as being able to diff new FreeBSD code against old FreeBSD code, and get something other than 400MB of cosmetic changes to header files and function prototypes. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 1:57:11 2002 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 7826C37B405 for ; Wed, 30 Jan 2002 01:57:08 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16VrWa-000GSH-00; Wed, 30 Jan 2002 11:59:28 +0200 From: Sheldon Hearn To: Poul-Henning Kamp Cc: Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 10:41:01 +0100." <21003.1012383661@critter.freebsd.dk> Date: Wed, 30 Jan 2002 11:59:28 +0200 Message-ID: <63256.1012384768@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, 30 Jan 2002 10:41:01 +0100, Poul-Henning Kamp wrote: > Plenty of innocent electrons have been wasted in the last 10 years > trying to prove that that the set "Terrys problems", is the most > important subset of the set "The FreeBSD projects problems", but > so far no evidence has been found to support this claim. As much as I don't like the look of the __P() construct, surely it's worthwhile if it means our code is easier to port to odd little embedded systems? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2: 2:22 2002 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 D587B37B417 for ; Wed, 30 Jan 2002 02:02:17 -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 g0U9xGr21282; Wed, 30 Jan 2002 10:59:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Your message of "Wed, 30 Jan 2002 01:52:28 PST." <3C57C25C.4C1EB64D@mindspring.com> Date: Wed, 30 Jan 2002 10:59:16 +0100 Message-ID: <21280.1012384756@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 <3C57C25C.4C1EB64D@mindspring.com>, Terry Lambert writes: >Poul, let me get this straight: people who use FreeBSD code >for uses other than what you personally use it for, and >people who take subsets of that code instead of taking the >code on an all or nothing basis like you appear to want can >"Bugger off"? No, but if we phrase it like this: People who want to use source code from FreeBSD on other systems or in other contexts than FreeBSD will have to do whatever it takes to do that. It is not FreeBSD's objective to stay diff(1) or even cc(1) compatible with every oddball platform in the world. >PS: "Terry's set of problems" includes being able to diff >FreeBSD code and NetBSD and OpenBSD code, as well as being >able to diff new FreeBSD code against old FreeBSD code, and >get something other than 400MB of cosmetic changes to header >files and function prototypes. More able hackers use scripts to deal with that problem. If you cared to think rather than preach you would quickly realize that it is simple to add __P() to prototyped include files with a script before you run diff(1). Another useful method is keeping a "baseline patch" around which contains already looked over diffs and apply that in reverse before diff'ing. Finally you would have more time to read your 400MB of diffs if you didn't wast so much time filling hot air into emails. Over and out... -- 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 Jan 30 2: 3:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 44CD037B402 for ; Wed, 30 Jan 2002 02:03:50 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 8DFA5216F; Wed, 30 Jan 2002 11:03:48 +0100 (CET) Date: Wed, 30 Jan 2002 11:03:48 +0100 From: Jeroen Ruigrok/asmodai To: Terry Lambert Cc: Dallas De Atley , arch@freebsd.org Subject: Re: __P macro question Message-ID: <20020130100347.GG22384@daemon.ninth-circle.org> References: <3C57B51B.F38D1906@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C57B51B.F38D1906@mindspring.com> User-Agent: Mutt/1.3.24i 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 [Lots of snipping of irrelevant diatribing(verbifying nouns while I am at it)] -On [20020130 10:00], Terry Lambert (tlambert2@mindspring.com) wrote: >Current policy is to not add the macro to new code, but to >not remove it on old code, in order to minimize gratuitous >changes to the source tree. Maintenance includes gratuitous changes, otherwise you can never fully reach a new situation in which clean-ups are present, and you keep lugging along stuff from decades ago with no real use to the world anymore. But then again, I prefer consistency and cleanliness over easiness for developers. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ Things do not change, we change... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2: 4:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 6033537B400 for ; Wed, 30 Jan 2002 02:04:39 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g0UA4hb01286; Wed, 30 Jan 2002 02:04:43 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200201301004.g0UA4hb01286@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dallas De Atley Cc: arch@freebsd.org Subject: Re: __P macro question In-reply-to: Your message of "Tue, 29 Jan 2002 20:15:27 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jan 2002 02:04:43 -0800 From: Michael 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 > I asked a question of our resident experts here at Apple and was > eventually directed to you by Jordan Hubbard. "I send you this for your consideration". G'day. 8) > My question was: What is the __P macro used for in all those > function declarations in the BSD libraries and do we still need it? It's used to hide function arguments from non-ANSI compilers. No, we don't still need it. > It was explained that this macro is used for pre-ANSI C compilers > and that while Darwin and thus Mac OS X compile with gcc 2.95, we retain > it in our code so that the diffs between our code and yours is small. > This enables the Darwin team to keep on top of changes between FreeBSD > and Darwin. That's not a bad reason, although the diffs are already pretty horrific. As a general rule, FreeBSD folk try to avoid gratuitous diffs where possible, hence __P() living on long after it should have died. > Is the __P macro still necessary? Are there pre ANSI C compilers > FreeBSD wishes to support or is this macro effectively benign but > useless? That would be a generous interpretation of the situation. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2: 4:55 2002 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 75ADC37B400 for ; Wed, 30 Jan 2002 02:04:48 -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 g0UA1ir21419; Wed, 30 Jan 2002 11:01:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Sheldon Hearn Cc: Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Your message of "Wed, 30 Jan 2002 11:59:28 +0200." <63256.1012384768@axl.seasidesoftware.co.za> Date: Wed, 30 Jan 2002 11:01:44 +0100 Message-ID: <21417.1012384904@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 <63256.1012384768@axl.seasidesoftware.co.za>, Sheldon Hearn writes: > > >On Wed, 30 Jan 2002 10:41:01 +0100, Poul-Henning Kamp wrote: > >> Plenty of innocent electrons have been wasted in the last 10 years >> trying to prove that that the set "Terrys problems", is the most >> important subset of the set "The FreeBSD projects problems", but >> so far no evidence has been found to support this claim. > >As much as I don't like the look of the __P() construct, surely it's >worthwhile if it means our code is easier to port to odd little embedded >systems? No it is not worthwhile, because the people who need the __P() for their odd little embedded systems can trivially insert __P() into our .h files with a script. -- 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 Jan 30 2: 5:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 373D137B404 for ; Wed, 30 Jan 2002 02:05:34 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0UA5ND82916; Wed, 30 Jan 2002 10:05:23 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 965CE71; Wed, 30 Jan 2002 10:00:16 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g0UA0GE33997; Wed, 30 Jan 2002 10:00:16 GMT (envelope-from mark@grondar.za) Message-Id: <200201301000.g0UA0GE33997@greenpeace.grondar.org> To: Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <3C57BED2.E1144F41@mindspring.com> In-Reply-To: <3C57BED2.E1144F41@mindspring.com> ; from Terry Lambert "Wed, 30 Jan 2002 01:37:22 PST." Date: Wed, 30 Jan 2002 10:00:11 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Said Terry Lambert : > You mean like when I compile "grep" and other command line tools > on my Amiga using Manx Aztec C, a K&R compiler? Yes. Except with those ancient compilers, you use KNRify or deprotoize, or one of a zillion tools to make ANSI code compliable on an antique compiler. > Or when I use Watcom to take some FreeBSD code for a POS system > to do the same thing for DR-DOS, because GCC won't run there > because it can't be compiled to use overlays? See above. > Really, if someone can't understand __P(), they should probably > not be in the kernel, with all those "dangerous" linker sets > and other less obvious code than __P()... Non sequitur. > > If the answer is "no", and I think it quite reasonably might be, then > > we can move forward with at least one assumption and that's that __P() > > can die in FreeBSD as something which merely obfuscates and renders > > our code more unpleasant to the eye. > > I think that portability of code between FreeBSD and OpenBSD > and NetBSD is a concern, and I think increasing the diffs > gratuitously between these systems is a Bad Idea(tm). Read their commit messages some time. They are slowly ansifying. > Also, as has already been raised, there is an issue of doing > back-ports of the code to FreeBSD X.Y, where X.Y is and of > the versions prior to the cosmetic make-over. Doing it properly will reduce the impact of this. > When NetBSD or OpenBSD gets new code (e.g. the SYN cache code > or the ipfilter license-inspired replacement), it would be > nice if porting the code would not require a human going > through and deciding which differences are there because they > need to be there, and which ones are there because of > gratuitous cosmetic changes. Terry - sooner or later a human has to look at the code to figure out which changes are needed. It happens. > > If you want my vote, and you get it whether that's the case or not, I > > say we nuke __P() from orbit until it and the unlucky disk platters it > > formerly rested on are reduced to a molten, bubbly, radioactive slag > > with the merest hint of ferrous particles still coating the surface. > > Can you get BSDI, NetBSD, and OpenBSD to go along with this? NetBSD and OpenBSD are already there AFAICT. (Not finished, but doing it) M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2: 9:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 82DE337B404 for ; Wed, 30 Jan 2002 02:09:45 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 7428E216F; Wed, 30 Jan 2002 11:09:44 +0100 (CET) Date: Wed, 30 Jan 2002 11:09:44 +0100 From: Jeroen Ruigrok/asmodai To: Terry Lambert Cc: Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130100944.GH22384@daemon.ninth-circle.org> References: <21003.1012383661@critter.freebsd.dk> <3C57C25C.4C1EB64D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C57C25C.4C1EB64D@mindspring.com> User-Agent: Mutt/1.3.24i 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 [20020130 11:00], Terry Lambert (tlambert2@mindspring.com) wrote: >PS: "Terry's set of problems" includes being able to diff >FreeBSD code and NetBSD and OpenBSD code, as well as being >able to diff new FreeBSD code against old FreeBSD code, and >get something other than 400MB of cosmetic changes to header >files and function prototypes. You cannot avoid that already: 1) register keyword removal 2) whitespace cleanups (some even mandated by style(9) purists) 3) proc to thread changes I think the list will continue for a while. Diffing 5.0 to 4.4BSD Lite2 is be a, erm, fun undertaking. Been there, done that, maintaining status quo will not help in any way. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ What is history but a fable agreed 'pon? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:10:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id BCF4137B416 for ; Wed, 30 Jan 2002 02:10:42 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id D06DD216F; Wed, 30 Jan 2002 11:10:41 +0100 (CET) Date: Wed, 30 Jan 2002 11:10:41 +0100 From: Jeroen Ruigrok/asmodai To: Sheldon Hearn Cc: Poul-Henning Kamp , Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130101041.GI22384@daemon.ninth-circle.org> References: <21003.1012383661@critter.freebsd.dk> <63256.1012384768@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63256.1012384768@axl.seasidesoftware.co.za> User-Agent: Mutt/1.3.24i 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 [20020130 11:00], Sheldon Hearn (sheldonh@starjuice.net) wrote: >As much as I don't like the look of the __P() construct, surely it's >worthwhile if it means our code is easier to port to odd little embedded >systems? Most of which at least support C89 or even C99 compilers, which thus support proper prototyping and have little use of the __P() macro. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ Look at his Soul, still searching for salvation... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:13:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 5925D37B400 for ; Wed, 30 Jan 2002 02:13:40 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g0UADib01384; Wed, 30 Jan 2002 02:13:44 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200201301013.g0UADib01384@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 11:59:28 +0200." <63256.1012384768@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jan 2002 02:13:44 -0800 From: Michael 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 > > Plenty of innocent electrons have been wasted in the last 10 years > > trying to prove that that the set "Terrys problems", is the most > > important subset of the set "The FreeBSD projects problems", but > > so far no evidence has been found to support this claim. > > As much as I don't like the look of the __P() construct, surely it's > worthwhile if it means our code is easier to port to odd little embedded > systems? Speaking as someone that's actually done this, rather than just blathered about it, __P() is about the least of your worries. The issue as Terry defends it is almost entirely irrelevant. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:18:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id C9BA737B400 for ; Wed, 30 Jan 2002 02:18:19 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Vrof-0005sD-00; Wed, 30 Jan 2002 02:18:09 -0800 Message-ID: <3C57C858.5FCC9453@mindspring.com> Date: Wed, 30 Jan 2002 02:18:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <21280.1012384756@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > No, but if we phrase it like this: > > People who want to use source code from FreeBSD on other systems > or in other contexts than FreeBSD will have to do whatever it > takes to do that. It is not FreeBSD's objective to stay > diff(1) or even cc(1) compatible with every oddball platform > in the world. You mean "portable to", not "compatible with". If the intent is no longer to act as a reference implementation for various code, then perhaps we should reconsider and release all of FreeBSD under the GPL, so it will be even more useless as a use-agnostic reference implementation. > >PS: "Terry's set of problems" includes being able to diff > >FreeBSD code and NetBSD and OpenBSD code, as well as being > >able to diff new FreeBSD code against old FreeBSD code, and > >get something other than 400MB of cosmetic changes to header > >files and function prototypes. > > More able hackers use scripts to deal with that problem. More able hackers use scripts to remove "offensive" things like "__P()" or even the contents of "#ifdef ALPHA" or other noop code for the platform they are using, rather than rendering the base code non-protable to all but their pet machines. > Another useful method is keeping a "baseline patch" around which > contains already looked over diffs and apply that in reverse before > diff'ing. Won't work in the context of back-porting from an unstable -current to a -stable a necessary patch, when you don't want to have to drink the "kernel interrupt threads" and other instability causing koolaid. > Finally you would have more time to read your 400MB of diffs if > you didn't wast so much time filling hot air into emails. Thanks for your concern, but I read very quickly. My concern was more general than for just myself. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:20:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id C538737B402 for ; Wed, 30 Jan 2002 02:20:33 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Vrqt-0006wc-00; Wed, 30 Jan 2002 02:20:27 -0800 Message-ID: <3C57C8E2.5D7F9DCC@mindspring.com> Date: Wed, 30 Jan 2002 02:20:18 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <63256.1012384768@axl.seasidesoftware.co.za> 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 Sheldon Hearn wrote: > > Plenty of innocent electrons have been wasted in the last 10 years > > trying to prove that that the set "Terrys problems", is the most > > important subset of the set "The FreeBSD projects problems", but > > so far no evidence has been found to support this claim. > > As much as I don't like the look of the __P() construct, surely it's > worthwhile if it means our code is easier to port to odd little embedded > systems? For what it's worth, I consider __P() to be incredibly ugly, but to be a necessary evil to ensure code portability. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:22:22 2002 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 93C7237B448 for ; Wed, 30 Jan 2002 02:22:17 -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 g0UAJGr21757; Wed, 30 Jan 2002 11:19:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Your message of "Wed, 30 Jan 2002 02:18:00 PST." <3C57C858.5FCC9453@mindspring.com> Date: Wed, 30 Jan 2002 11:19:16 +0100 Message-ID: <21755.1012385956@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 <3C57C858.5FCC9453@mindspring.com>, Terry Lambert writes: Hi Terry, I can see from your more and more irrellevant argumentation that you have realized the battle is lost and now you are just trying to save face. You can save a lot of time for all of us (time which we can then spend on improving FreeBSD) if you just shut up now. Thanks in advance! -- 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 Jan 30 2:30:15 2002 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 29DBA37B400; Wed, 30 Jan 2002 02:30:09 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16Vs36-000GX4-00; Wed, 30 Jan 2002 12:33:04 +0200 From: Sheldon Hearn To: Michael Smith Cc: arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 02:13:44 PST." <200201301013.g0UADib01384@mass.dis.org> Date: Wed, 30 Jan 2002 12:33:03 +0200 Message-ID: <63553.1012386783@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, 30 Jan 2002 02:13:44 PST, Michael Smith wrote: > Speaking as someone that's actually done this, rather than just blathered > about it, __P() is about the least of your worries. > > The issue as Terry defends it is almost entirely irrelevant. Great. I got quite excited when Mark Murray made noises about cleansing the userland source code of __P(). I think the original idea was to do it for HEAD only, to avoid unnecessary deltas for RELENG_4 cvsup users. Since 5.0-RELEASE has been delayed, it probably doesn't make sense for the purge to happen until the advent of the RELENG_5 branch. We don't want gratuitous diffs like this making merges onto RELENG_4 difficult. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:31:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 223D337B402 for ; Wed, 30 Jan 2002 02:31:51 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g0UAW1b01550 for ; Wed, 30 Jan 2002 02:32:02 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200201301032.g0UAW1b01550@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 02:20:18 PST." <3C57C8E2.5D7F9DCC@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jan 2002 02:32:01 -0800 From: Michael 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 > For what it's worth, I consider __P() to be incredibly ugly, > but to be a necessary evil to ensure code portability. It's inadequate, and such a trivial aid to "portability" compared to its nuisance value otherwise that maintaining it makes no sense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:32:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 4A4DC37B400 for ; Wed, 30 Jan 2002 02:32:08 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Vs26-0004Ob-00; Wed, 30 Jan 2002 02:32:03 -0800 Message-ID: <3C57CB99.7837041@mindspring.com> Date: Wed, 30 Jan 2002 02:31:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <21755.1012385956@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > Hi Terry, > > I can see from your more and more irrellevant argumentation that > you have realized the battle is lost and now you are just trying > to save face. > > You can save a lot of time for all of us (time which we can then > spend on improving FreeBSD) if you just shut up now. > > Thanks in advance! Hi Poul, Thanks for attacking me instead of my arguments, since it validates them far better than any amount of posting by me could ever do, and is far more helpful than, say, dispassionately refuting them would have been. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:32:36 2002 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 D2C0337B405 for ; Wed, 30 Jan 2002 02:32:28 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16Vs4o-000GXy-00; Wed, 30 Jan 2002 12:34:50 +0200 From: Sheldon Hearn To: Terry Lambert Cc: Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 02:20:18 PST." <3C57C8E2.5D7F9DCC@mindspring.com> Date: Wed, 30 Jan 2002 12:34:50 +0200 Message-ID: <63609.1012386890@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, 30 Jan 2002 02:20:18 PST, Terry Lambert wrote: > For what it's worth, I consider __P() to be incredibly ugly, > but to be a necessary evil to ensure code portability. Someone else pointed out that conversion from ANSI C to K&R C with respect to __P() is probably scriptable. I don't suppose you have a script like that lying around, for inclusion in src/tools/tools? :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:33:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id CDF5437B404 for ; Wed, 30 Jan 2002 02:33:27 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 882DB216F; Wed, 30 Jan 2002 11:33:26 +0100 (CET) Date: Wed, 30 Jan 2002 11:33:26 +0100 From: Jeroen Ruigrok/asmodai To: Terry Lambert Cc: Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130103326.GJ22384@daemon.ninth-circle.org> References: <21280.1012384756@critter.freebsd.dk> <3C57C858.5FCC9453@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C57C858.5FCC9453@mindspring.com> User-Agent: Mutt/1.3.24i 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 [20020130 11:22], Terry Lambert (tlambert2@mindspring.com) wrote: >Poul-Henning Kamp wrote: > >If the intent is no longer to act as a reference implementation >for various code, then perhaps we should reconsider and release >all of FreeBSD under the GPL, so it will be even more useless >as a use-agnostic reference implementation. > Acting as a reference implementation does _NOT_ mandate sticking to an old specification of C. Furthermore, putting it under GPL is a logical(?) step I cannot even imagine how you came to that. >More able hackers use scripts to remove "offensive" things >like "__P()" or even the contents of "#ifdef ALPHA" or other >noop code for the platform they are using, rather than >rendering the base code non-protable to all but their pet >machines. Real hackers would use unifdef(1) for the #ifdef's. Anyway, are you scared of ANSI C? Your argumentation is starting to border on the point of fright of moving forward to a standard a bit closer to what people are actually taught in schools nowadays. Most people don't even KNOW K&R C anymore, let alone use it. So moving to an ANSI standard in today's world might even be better to continue to act as a reference platform. >> Another useful method is keeping a "baseline patch" around which >> contains already looked over diffs and apply that in reverse before >> diff'ing. > >Won't work in the context of back-porting from an unstable >-current to a -stable a necessary patch, when you don't >want to have to drink the "kernel interrupt threads" and >other instability causing koolaid. Backporting is already a pain in the arse, having just recently been through backporting Scott Long's UDF driver to STABLE. And that's new code not even in CURRENT nor in STABLE, just making use of the APIs and supplied functionality. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ Hope sees the invisible, feels the intangible and achieves the impossible... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:34:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 0554D37B416 for ; Wed, 30 Jan 2002 02:34:10 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g0UAYLb01598 for ; Wed, 30 Jan 2002 02:34:21 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200201301034.g0UAYLb01598@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 12:33:03 +0200." <63553.1012386783@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jan 2002 02:34:21 -0800 From: Michael 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 > I think the original idea was to do it for HEAD only, to avoid unnecessary > deltas for RELENG_4 cvsup users. Since 5.0-RELEASE has been delayed, it > probably doesn't make sense for the purge to happen until the advent of > the RELENG_5 branch. We don't want gratuitous diffs like this making > merges onto RELENG_4 difficult. Actually, eliminating __P() will have little or no effect on merge activity. It's a headerfile construct, typically only found in function prototype blocks. The sort of noise that would be generated by removing it is fairly trivially identified and ignored, compared to any of the other, massively intrusive changes that are going on. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:35:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 1DA1F37B402 for ; Wed, 30 Jan 2002 02:35:44 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Vs5U-0004X3-00; Wed, 30 Jan 2002 02:35:33 -0800 Message-ID: <3C57CC6B.485DBAA1@mindspring.com> Date: Wed, 30 Jan 2002 02:35:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <63609.1012386890@axl.seasidesoftware.co.za> 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 Sheldon Hearn wrote: > On Wed, 30 Jan 2002 02:20:18 PST, Terry Lambert wrote: > > For what it's worth, I consider __P() to be incredibly ugly, > > but to be a necessary evil to ensure code portability. > > Someone else pointed out that conversion from ANSI C to K&R C with > respect to __P() is probably scriptable. Yes, Poul did. I pointed out that the reverse was also true. > I don't suppose you have a script like that lying around, for inclusion > in src/tools/tools? :-) If you want, I can give you a script for src/usr/tools that will strip them out so that you don't have to look at them on your own machine, instead, and then we can just leave them in the CVS repository... 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:36:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 5112137B400 for ; Wed, 30 Jan 2002 02:36:33 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g0UAa0b01619; Wed, 30 Jan 2002 02:36:04 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200201301036.g0UAa0b01619@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Sheldon Hearn Cc: Terry Lambert , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 12:34:50 +0200." <63609.1012386890@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jan 2002 02:36:00 -0800 From: Michael 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 > Someone else pointed out that conversion from ANSI C to K&R C with > respect to __P() is probably scriptable. > > I don't suppose you have a script like that lying around, for inclusion > in src/tools/tools? :-) Look for 'unprotoize' in the gcc sources in src/contrib. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:40:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 73E4D37B402 for ; Wed, 30 Jan 2002 02:40:36 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16VsAE-0006lZ-00; Wed, 30 Jan 2002 02:40:26 -0800 Message-ID: <3C57CD90.351F9AD5@mindspring.com> Date: Wed, 30 Jan 2002 02:40:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/asmodai Cc: Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <21280.1012384756@critter.freebsd.dk> <3C57C858.5FCC9453@mindspring.com> <20020130103326.GJ22384@daemon.ninth-circle.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeroen Ruigrok/asmodai wrote: > Anyway, are you scared of ANSI C? > Your argumentation is starting to border on the point of fright of > moving forward to a standard a bit closer to what people are actually > taught in schools nowadays. Microsoft Visual C++? 8-). > Most people don't even KNOW K&R C anymore, let alone use it. So moving > to an ANSI standard in today's world might even be better to continue to > act as a reference platform. ANSI C is less portable than K&R C, and ANSI compilers will compile K&R C. I would suggest avoiding bitfields, and byte order dependent coding, too, if you want the code to be portable. > Backporting is already a pain in the arse, having just recently been > through backporting Scott Long's UDF driver to STABLE. And that's new > code not even in CURRENT nor in STABLE, just making use of the APIs and > supplied functionality. Then by all means, make it even harder, for aesthetic reasons. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:45:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 9B00837B400 for ; Wed, 30 Jan 2002 02:45:12 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0UAjBK83245 for arch@FreeBSD.ORG; Wed, 30 Jan 2002 10:45:11 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id D3C7F39 for ; Wed, 30 Jan 2002 10:41:16 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g0UAfGE75817 for ; Wed, 30 Jan 2002 10:41:16 GMT (envelope-from mark@grondar.za) Message-Id: <200201301041.g0UAfGE75817@greenpeace.grondar.org> To: arch@FreeBSD.ORG Subject: Re: __P macro question References: <63609.1012386890@axl.seasidesoftware.co.za> In-Reply-To: <63609.1012386890@axl.seasidesoftware.co.za> ; from Sheldon Hearn "Wed, 30 Jan 2002 12:34:50 +0200." Date: Wed, 30 Jan 2002 10:41:11 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Said Sheldon Hearn : > Someone else pointed out that conversion from ANSI C to K&R C with > respect to __P() is probably scriptable. > > I don't suppose you have a script like that lying around, for inclusion > in src/tools/tools? :-) unprotoize.c, ansi2knr.c Lots more if you Hunt The Net(tm). M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:46: 8 2002 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 626EA37B404; Wed, 30 Jan 2002 02:46:06 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16VsIW-000GdO-00; Wed, 30 Jan 2002 12:49:00 +0200 From: Sheldon Hearn To: Michael Smith Cc: Terry Lambert , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 02:36:00 PST." <200201301036.g0UAa0b01619@mass.dis.org> Date: Wed, 30 Jan 2002 12:49:00 +0200 Message-ID: <63945.1012387740@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, 30 Jan 2002 02:36:00 PST, Michael Smith wrote: > > I don't suppose you have a script like that lying around, for inclusion > > in src/tools/tools? :-) > > Look for 'unprotoize' in the gcc sources in src/contrib. Hell, if it's there already, then there's nothing left to do but wait for the RELENG_5 branch. :-) Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 2:47: 0 2002 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 6C97037B402; Wed, 30 Jan 2002 02:46:57 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16VsJM-000Gdv-00; Wed, 30 Jan 2002 12:49:52 +0200 From: Sheldon Hearn To: Michael Smith Cc: arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 02:34:21 PST." <200201301034.g0UAYLb01598@mass.dis.org> Date: Wed, 30 Jan 2002 12:49:52 +0200 Message-ID: <63978.1012387792@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, 30 Jan 2002 02:34:21 PST, Michael Smith wrote: > Actually, eliminating __P() will have little or no effect on merge > activity. It's a headerfile construct, typically only found in function > prototype blocks. The sort of noise that would be generated by removing > it is fairly trivially identified and ignored, compared to any of the > other, massively intrusive changes that are going on. So then it's just a case of unnecessary deltas for -STABLE cvsup users. Or is there an argument against that as well? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 4:56:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from shark.amis.net (shark.amis.net [212.18.32.14]) by hub.freebsd.org (Postfix) with ESMTP id 6C53B37B400 for ; Wed, 30 Jan 2002 04:56:14 -0800 (PST) Received: from baracuda.amis.net (baracuda.amis.net [212.18.32.4]) by shark.amis.net (Postfix) with ESMTP id ECF1B7CBD; Wed, 30 Jan 2002 13:56:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by baracuda.amis.net (Postfix) with ESMTP id B8BAA9B14; Wed, 30 Jan 2002 13:56:09 +0100 (CET) Received: from titanic.medinet.si (titanic.medinet.si [212.18.42.5]) by baracuda.amis.net (Postfix) with ESMTP id DA3569B13; Wed, 30 Jan 2002 13:56:08 +0100 (CET) Received: by titanic.medinet.si (Postfix, from userid 1000) id 3448955414; Wed, 30 Jan 2002 13:56:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by titanic.medinet.si (Postfix) with ESMTP id 3219455412; Wed, 30 Jan 2002 13:56:08 +0100 (CET) Date: Wed, 30 Jan 2002 13:56:07 +0100 (CET) From: Blaz Zupan X-X-Sender: blaz@titanic.medinet.si To: Jordan Hubbard Cc: arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: <64972.1012382408@winston.freebsd.org> Message-ID: <20020130135514.B74305-100000@titanic.medinet.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > If you want my vote, and you get it whether that's the case or not, I > say we nuke __P() from orbit until it and the unlucky disk platters it > formerly rested on are reduced to a molten, bubbly, radioactive slag > with the merest hint of ferrous particles still coating the surface. Jordan, I congratulate you on this paragraph and suggest you commit it as a fortune cookie :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 8:24: 9 2002 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 34B5337B41B for ; Wed, 30 Jan 2002 08:23:55 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0UGMlo67434; Wed, 30 Jan 2002 08:22:47 -0800 (PST) (envelope-from obrien) Date: Wed, 30 Jan 2002 08:22:47 -0800 From: "David O'Brien" To: Jeroen Ruigrok/asmodai Cc: Terry Lambert , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130082247.A67274@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <21280.1012384756@critter.freebsd.dk> <3C57C858.5FCC9453@mindspring.com> <20020130103326.GJ22384@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020130103326.GJ22384@daemon.ninth-circle.org>; from asmodai@wxs.nl on Wed, Jan 30, 2002 at 11:33:26AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 30, 2002 at 11:33:26AM +0100, Jeroen Ruigrok/asmodai wrote: > Real hackers would use unifdef(1) for the #ifdef's. Someone please explain what is so bad with __P() ; or is this just the small bike shed everyone can possibly undrestand sufficently to comment on? > Anyway, are you scared of ANSI C? Are you scared of K&R C? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 8:32:46 2002 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 08E9137B416 for ; Wed, 30 Jan 2002 08:32:43 -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 g0UGWfo30077 for ; Wed, 30 Jan 2002 09:32:41 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0UGWfx24716 for ; Wed, 30 Jan 2002 09:32:41 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 09:32:18 -0700 (MST) Message-Id: <20020130.093218.75902427.imp@village.org> To: arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <3C57C858.5FCC9453@mindspring.com> References: <21280.1012384756@critter.freebsd.dk> <3C57C858.5FCC9453@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It is my intent to start removing __P wholesale from userland (not files on vendor branches other than the lite branch) in earnest a little at a time between now and 5.0. I'm avoiding the kernel for the moment. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 8:34: 2 2002 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 BA81D37B402; Wed, 30 Jan 2002 08:33:56 -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 g0UGXto30099; Wed, 30 Jan 2002 09:33:55 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0UGXsx24735; Wed, 30 Jan 2002 09:33:55 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 09:33:32 -0700 (MST) Message-Id: <20020130.093332.43527556.imp@village.org> To: sheldonh@starjuice.net Cc: msmith@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <63553.1012386783@axl.seasidesoftware.co.za> References: <200201301013.g0UADib01384@mass.dis.org> <63553.1012386783@axl.seasidesoftware.co.za> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <63553.1012386783@axl.seasidesoftware.co.za> Sheldon Hearn writes: : I think the original idea was to do it for HEAD only, to avoid unnecessary : deltas for RELENG_4 cvsup users. Since 5.0-RELEASE has been delayed, it : probably doesn't make sense for the purge to happen until the advent of : the RELENG_5 branch. We don't want gratuitous diffs like this making : merges onto RELENG_4 difficult. I disagree. This is why we didn't do it before 4.0 with s/4/3/;s/5/4/. We should just do it. If we need to, we can MFC the changes that get in the way. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 8:35:49 2002 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 9E9DE37B402 for ; Wed, 30 Jan 2002 08:35:33 -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 g0UGZWo30116 for ; Wed, 30 Jan 2002 09:35:32 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0UGZVx24750 for ; Wed, 30 Jan 2002 09:35:31 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 09:35:09 -0700 (MST) Message-Id: <20020130.093509.122164658.imp@village.org> To: arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <63945.1012387740@axl.seasidesoftware.co.za> References: <200201301036.g0UAa0b01619@mass.dis.org> <63945.1012387740@axl.seasidesoftware.co.za> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <63945.1012387740@axl.seasidesoftware.co.za> Sheldon Hearn writes: : Hell, if it's there already, then there's nothing left to do but wait : for the RELENG_5 branch. :-) I'm tired of this coming up all the time and don't plan to wait unless a compelling reason comes up. My experience with MFC is that __P removal isn't a problem. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 9:33:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.68.253]) by hub.freebsd.org (Postfix) with ESMTP id C4FBA37B405 for ; Wed, 30 Jan 2002 09:33:51 -0800 (PST) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id CAA24465 for ; Thu, 31 Jan 2002 02:32:09 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200201301732.CAA24465@shidahara1.planet.sci.kobe-u.ac.jp> To: freebsd-arch@freebsd.org Subject: How about removing #ifdef DEV_ISA from autoconf.c Date: Thu, 31 Jan 2002 02:32:09 +0900 From: Takanori Watanabe Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I have a patch to be reviewed. This removes #ifdef DEV_ISA from sys/i386/autoconf.c and allows to intercept before and after isa_prove_children() executed. This will enable us statisize isa_probe_children, though what I want to do is to execute isa_probe_children-like routine in acpi module after isa_probe_children is exeuted. This patch contains patch to i386/i386/autoconf.h and isa/isa_common.c and new sys/autoconf.h file. How do you think about it? Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A begin 644 isadiff.tar.gz M'XL("*LD6#P``VES861I9F8N=&%R`.U865/C1A#FU?X576P5:UL^=-B6UVQ2 M$&P2IXC9LDV*?5(-TAC/(DLJ:<215/Y[>D8^9&../+!4DOD*A&GU-3TS7S>P MA#AN.)^'0=UCT^G>6\#0]7:S"7L`AMW2\S\E#--L`=A-LZV;IM&V46+9EKT' M^IMDLX4TX20&V./DAMP13I[2>^G]OQ2U6@T::1(W9N&<-I:+;!`W8K5O42.) MW4;RD#180L3W\JBXA+,A=N0>8N*!%-VG<:T M)$45#PM=7NL][6C\=3P8#B:EE0/4J,)XX(PO?G).SH>G@Y\O1GTI.1_U^J.% MS!F,CZN;D:MPL.E=Q']EID7MSZ(F[NLJT0I^BN`'$*\/LW?".HK#*^I@77TO MID%):HDXHFJP",4"7I3*A'/<@M+*)WXH%]_[4OR/L+H9[KOQOV6VFRO^UVU+ M\'^[92G^_QYX+?];G7;V6!^8[1Y@=%NY'K"EE^L`G6[36G>`IN19?+8ES4(% M2.`!GU'P8G9+XP1(3)$O&&?$9W]0KRZ4&CD2WP\C[ER%(8_JL_UB;5..'".D M6]K!--DMC='-CC>RV>S+?#O-JH$)=ZRJ868]B_H)S?>4K%:B8;IIUJ)H@'<+ M&A4X_C(X<0;G(O^:R'3JT2GT^K\+JLYE_GG1;F])+!R@ZA/-`78#T;]GCX=;-DN/GK>-FVM*RJJ8-F-#M5HREW!F3"@S#.[BC'U$_IL1[`!["#'D&EU.* MQ-D(KLMB)J%QG$8\J4N;R\M+Y"%<.GXE/KN>>)IDUXQ^3Q:P%08B7 MFO"E,6=S"M,P!K28T9C6I05R2@&O3VEKPD-I8<=8]F@.7+)(+;>"?UHV:?12 MW;)<-X;.G>SAI?/Y@QP[H8#&NMA2.7J_=\_\+V'=)-XNQ@OS'QC&>OXS]9;X MCX!MM-3\]SWP(>NKN_YV!-#O<>L0Q2>UL)&@5B?3>N^U*"@H*"@H*"@H*"@H 4*"@H*"@H*"@HK/$W$,@GH0`H```0 ` end To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 9:50:17 2002 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 DDE9F37B404 for ; Wed, 30 Jan 2002 09:50:14 -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 g0UHnWd66471; Wed, 30 Jan 2002 09:49:32 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Terry Lambert Cc: Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Message from Terry Lambert of "Wed, 30 Jan 2002 01:37:22 PST." <3C57BED2.E1144F41@mindspring.com> Date: Wed, 30 Jan 2002 09:49:32 -0800 Message-ID: <66467.1012412972@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 > You mean like when I compile "grep" and other command line tools > on my Amiga using Manx Aztec C, a K&R compiler? The utter obsolescence of your Amiga aside (heck, I gave my A2500 away many years ago), I think I've already made the point that there are other sources for grep for these sorts of exercises in retrocomputing. FreeBSD is not trying to be everything to everyone - we have other *BSDs which fill other niches and other code bases (the historical USL stuff already mentioned) which fill needs like this. > Really, if someone can't understand __P(), they should probably > not be in the kernel, with all those "dangerous" linker sets > and other less obvious code than __P()... That's a total Red Herring. It was never stated that people "couldn't understand" __P() - we're talking about code clutter and asthetic appeal, something I'd expect an Amiga owner to understand. :) > Can you get BSDI, NetBSD, and OpenBSD to go along with this? BSD/OS is frankly of no concern, being another tiny niche player (see comments about the Amiga again), but I'll bet there would be less resistance from the {Net,Open}BSD camps than you think. Even the NetBSD/amiga port uses gcc. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 9:52:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 111A737B417; Wed, 30 Jan 2002 09:52:08 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 81887216E; Wed, 30 Jan 2002 18:52:02 +0100 (CET) Date: Wed, 30 Jan 2002 18:52:02 +0100 From: Jeroen Ruigrok/asmodai To: David O'Brien Cc: Terry Lambert , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130175201.GL22384@daemon.ninth-circle.org> References: <21280.1012384756@critter.freebsd.dk> <3C57C858.5FCC9453@mindspring.com> <20020130103326.GJ22384@daemon.ninth-circle.org> <20020130082247.A67274@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020130082247.A67274@dragon.nuxi.com> User-Agent: Mutt/1.3.24i 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 [20020130 17:33], David O'Brien (obrien@FreeBSD.ORG) wrote: >On Wed, Jan 30, 2002 at 11:33:26AM +0100, Jeroen Ruigrok/asmodai wrote: >> Real hackers would use unifdef(1) for the #ifdef's. > >Someone please explain what is so bad with __P() ; or is this just the >small bike shed everyone can possibly undrestand sufficently to comment >on? I cannot fully oomment on the motiviations of others. For me it is the fact that there is no consistency. And the facts that: 1) two ANSI C standards have passed, lets put some effort in making use of the features they provide 2) it solves a problem not present in ANSI C, namely prototype support, see #1 3) it is a macro, macros tend to hide things [the preprocessor is a blunt tool to use] Also, commenting this to be a bikeshed while it is a serious request/question about code maintainability and clean-ups is not really constructive. Since you were friendly enough not to provide any constructive feedback whatsoever towards the issue other than labeling it a bikeshed, let me ask something in return: What is __P()'s higher motive and function that it needs to be present still? >> Anyway, are you scared of ANSI C? > >Are you scared of K&R C? Bad practices scare me. And K&R has been discussed to death on various fori before, and the large majority agreed that it should be replaced by ANSI C89 at least. If you do not start somewhere, you will never arrive anywhere. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ You're just like a vapor, that appears for a little while and vanishes one day... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 9:57: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sushi.sanyusan.se (h12n2fls34o835.telia.com [213.67.31.12]) by hub.freebsd.org (Postfix) with ESMTP id 3D32137B402 for ; Wed, 30 Jan 2002 09:57:02 -0800 (PST) Received: (from anders@localhost) by sushi.sanyusan.se (8.11.6/8.11.6) id g0UHueU12089; Wed, 30 Jan 2002 18:56:40 +0100 (CET) (envelope-from anders) Date: Wed, 30 Jan 2002 18:56:40 +0100 From: Anders Andersson To: Jordan Hubbard Cc: Terry Lambert , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130175639.GB2437@sushi.sanyusan.se> References: <3C57BED2.E1144F41@mindspring.com> <66467.1012412972@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66467.1012412972@winston.freebsd.org> User-Agent: Mutt/1.3.27i Sender: owner-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, Jan 30, 2002 at 09:49:32AM -0800, Jordan Hubbard wrote: > Even the NetBSD/amiga port uses gcc. NetBSD/amiga just very recently got ANSIfied also :-) -- Anders Andersson UNIX, Networking and Security consultant +46 (0)705 87 53 35 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 9:57:18 2002 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 512D137B400 for ; Wed, 30 Jan 2002 09:57:14 -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 g0UHuKd66506; Wed, 30 Jan 2002 09:56:20 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Terry Lambert Cc: Poul-Henning Kamp , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Message from Terry Lambert of "Wed, 30 Jan 2002 02:18:00 PST." <3C57C858.5FCC9453@mindspring.com> Date: Wed, 30 Jan 2002 09:56:20 -0800 Message-ID: <66502.1012413380@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 > > If the intent is no longer to act as a reference implementation > for various code, then perhaps we should reconsider and release > all of FreeBSD under the GPL, so it will be even more useless > as a use-agnostic reference implementation. > Well, now that we've gone into content-free mode I guess it's time to invoke Hitler and end this discussion.. :-) If I had any lingering dowbts about the advisability of going on a Jihad against __P(), Terry has managed to remove them. I think the next step is to decide on a schedule for axing them from -current, before 5.0 comes out. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 10:39:12 2002 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 CB25237B404 for ; Wed, 30 Jan 2002 10:39:05 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 8AA0E5343; Wed, 30 Jan 2002 19:39:02 +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: Julian Elischer Cc: Doug White , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. References: From: Dag-Erling Smorgrav Date: 30 Jan 2002 19:39:01 +0100 In-Reply-To: Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer writes: > I'm not actually looking for a gdb maintainer, so much as someone who > understands teh KERNEL side of how gdb controls a process. That'd be me. Feel free to ask any questions you might have. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 10:43:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by hub.freebsd.org (Postfix) with ESMTP id 334AD37B488 for ; Wed, 30 Jan 2002 10:43:18 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailf.telia.com (8.11.6/8.11.6) with ESMTP id g0UIhF310054 for ; Wed, 30 Jan 2002 19:43:16 +0100 (CET) Received: from falcon.midgard.homeip.net (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id TAA01140 for ; Wed, 30 Jan 2002 19:43:14 +0100 (CET) Received: (qmail 10907 invoked by uid 1001); 30 Jan 2002 18:43:12 -0000 Date: Wed, 30 Jan 2002 19:43:11 +0100 From: Erik Trulsson To: Jordan Hubbard Cc: Terry Lambert , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130184311.GA10841@student.uu.se> Mail-Followup-To: Jordan Hubbard , Terry Lambert , Dallas De Atley , arch@FreeBSD.ORG References: <3C57BED2.E1144F41@mindspring.com> <66467.1012412972@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66467.1012412972@winston.freebsd.org> User-Agent: Mutt/1.3.25i Sender: owner-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, Jan 30, 2002 at 09:49:32AM -0800, Jordan Hubbard wrote: > > You mean like when I compile "grep" and other command line tools > > on my Amiga using Manx Aztec C, a K&R compiler? > > The utter obsolescence of your Amiga aside (heck, I gave my A2500 away > many years ago), I think I've already made the point that there are > other sources for grep for these sorts of exercises in retrocomputing. I strongly disagree that the Amiga is utterly obsolete (I still use my A1200 :-) ), but Terry's comment is irrelevant anyway. The reason for this is that there are several ANSI C compilers available for the Amiga (including gcc) so there is no need to use a K&R compiler there. I believe there are very few platforms in active use today that do not have an ANSI C compiler available. (With the possible exceptions of CP/M and C64 and older embedded CPUs, none of which I think FreeBSD need to worry much about.) On the whole I think there is very little need to worry about K&R compatibility today. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 10:56:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by hub.freebsd.org (Postfix) with SMTP id BE8F337B41B for ; Wed, 30 Jan 2002 10:56:20 -0800 (PST) Received: (qmail 83995 invoked from network); 30 Jan 2002 18:56:19 -0000 Received: from nat.ironport.com (HELO ?10.1.1.121?) (63.251.108.100) by relay1.pair.com with SMTP; 30 Jan 2002 18:56:19 -0000 X-pair-Authenticated: 63.251.108.100 Mime-Version: 1.0 X-Sender: markfree@mail.peek.org Message-Id: In-Reply-To: <20020129120723.A81682@dragon.nuxi.com> References: <21096.1012296566@axl.seasidesoftware.co.za> <20020129112202.D48817-100000@resnet.uoregon.edu> <20020129120723.A81682@dragon.nuxi.com> Date: Wed, 30 Jan 2002 10:48:15 -0800 To: obrien@FreeBSD.ORG From: Mark Peek Subject: Re: KSE milestone 3 reached. Cc: Sheldon Hearn , Julian Elischer , arch@FreeBSD.ORG, Doug White 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:07 PM -0800 1/29/02, David O'Brien wrote: >On Tue, Jan 29, 2002 at 11:22:36AM -0800, Doug White wrote: >> On Tue, 29 Jan 2002, Sheldon Hearn wrote: >> >> > As an aside, if your search for gdb maintainers bears fruit, please let >> > me know. The rest of the PR workers and I would very much like to know >> > who to assign all Kip Macy's PRs to. :-) >> >> Apparently my attempts to trick Kip Macy into taking over gdb >> maintainership have yet to ripen. :) > >I thought we also had roped Mark Peek into that job. :-) Oops...we talked about it but I didn't know it actually happened. I thought you were still handling it. Can I have permission to override your maintainer bit for ports/gdb51 and gnu/usr.bin/binutils/gdb as needed to fix bugs and update it? Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 11: 5:32 2002 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 7879537B43C for ; Wed, 30 Jan 2002 11:05:05 -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 g0UJ50J120360; Wed, 30 Jan 2002 14:05:00 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Wed, 30 Jan 2002 14:04:58 -0500 To: Dallas De Atley , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: __P macro question Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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 8:15 PM -0800 1/29/02, Dallas De Atley wrote: > After doing a little bit of homework searching cdef.h and >style.9 and encountering old jokes concerning the coming of Jesus >(thank you Google), I decided to pursue the question. > > Is the __P macro still necessary? Are there pre ANSI C >compilers FreeBSD wishes to support or is this macro effectively >benign but useless? We (freebsd developers) have this debate every six months or so. Each time, the overwhelming majority of developers will be happy to see __P() disappear. However, there is also general agreement that we shouldn't do some big sweep of the code just to remove __P()'s. So, the feeling is that if you are changing some section of code for some other reason, then it would be a fine idea to also write an update (a separate update...) which would "ANSI-fy" the code. One exception to this is the main system include libraries. The feeling seems to be that these could wait, and if these are switched at all then they can be the last things switched over. So, several months go by, some new person comes along, and asks the question again. Then all the people who want to KEEP the __P()'s act as if this is some brand new issue, and that we must debate it to death once again. I think no debate is necessary. The decision has already been reached, several times, that __P() can go. Anyone who makes an update to ANSI-fy some code will probably get some grumbling about "breaking K&R conformance", but at this point I think that specific complaint should just be ignored. The year is now 2002, and not 1988. I also think that maybe we *do* need a specific code-sweep which does nothing but (carefully) remove all the __P()'s, if for no other reason than to avoid seeing this debate again in six to eight months. -- 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 Jan 30 11: 7:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 0D2B837B404 for ; Wed, 30 Jan 2002 11:07:46 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g0UJ7jM11721 for ; Wed, 30 Jan 2002 11:07:45 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g0UJ7ii04164; Wed, 30 Jan 2002 11:07:44 -0800 (PST) (envelope-from jdp) Date: Wed, 30 Jan 2002 11:07:44 -0800 (PST) Message-Id: <200201301907.g0UJ7ii04164@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Subject: Re: __P macro question In-Reply-To: <63553.1012386783@axl.seasidesoftware.co.za> References: <63553.1012386783@axl.seasidesoftware.co.za> Organization: Polstra & Co., Seattle, WA Sender: owner-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 <63553.1012386783@axl.seasidesoftware.co.za>, Sheldon Hearn wrote: > > Great. I got quite excited when Mark Murray made noises about cleansing > the userland source code of __P(). > > I think the original idea was to do it for HEAD only, to avoid unnecessary > deltas for RELENG_4 cvsup users. I wouldn't worry about that. Keep in mind that just making a release creates a lot of deltas. This change would be no different than any other change to the source tree. It's either worth making the change, or it isn't. CVSup doesn't have much to do with it. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 11:20:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id A123037B400 for ; Wed, 30 Jan 2002 11:20:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020130192015.ZJBR10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 30 Jan 2002 19:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA57275; Wed, 30 Jan 2002 11:12:58 -0800 (PST) Date: Wed, 30 Jan 2002 11:12:57 -0800 (PST) From: Julian Elischer To: Dag-Erling Smorgrav Cc: Doug White , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. 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 In a threaded world, the assumption that gdb makes in teh current kernel that 1 process == 1 thread totally breaks down. Another thing that breaks down is the way in which processes are suspended. This also impacts on how processes are debugged as suspending the process is part of debugging it. I have made the following changes: Addition of three 'suspended' flags in the process structure flag word. One for a new concept "singlethreading", one to indicate that the process received a SIGSTOP or SIGTSTP and one to indicate that the process was asked to stop for tracing reasons. If any of these three are set, then any associated threads will refuse to go to user mode but will instead block at userret() and be placed upon a special 'suspended' queue off the process itself. "Singlethreading" is a suspension mode where a thread requests that all threads OTHER THAN ITSELF be placed into suspended mode (or in fact forced to call thread_exit()). This is required during such things as fork(), exit() , exec(). The requesting thread is itself suspended and placed on a special hook until all the other threads have suspended or died, at which time it is made runnable again. The current debug code seems to call psignal to deliver STOP signals in order to suspend the process, and the stuff SEF did actually makes teh processes call msleep(). I hope to replace all these calls in both systems with calls to new functions trace_suspend(p) and trace_unsuspend(p). So that both sets of debug code use the same mechanism. The difficult part is to decide how the interface should be modified to debug single threads. For example: do you want all teh other threads to be suspended, or to be running? Do you want the UTS to be suspended as well? User threads are identified by the address of their mailbox. The UTS has it's own mailbox (per cpu) and when it schedules a thread to run, it places a pointer to that thread's mailbox in a know location in ITS mailbox. If there is a trap or syscall, and the kernel is entered, that entry is examined and thus the kernel knows the mailbox address of the currently running thread. It would be possible to only suspend a thread that has a particular address, or to only allow a thread with that mailbox address to continue, etc. When teh UTS is running itself that entry contains NULL. This on any kernel entry, the kernel can tell if the user thread running is the one it is interested in or not, or if the UTS itself is running. I have not completed this work yet.. but am wondering if you have any violent arguments about what I'm doing.. On 30 Jan 2002, Dag-Erling Smorgrav wrote: > Julian Elischer writes: > > I'm not actually looking for a gdb maintainer, so much as someone who > > understands teh KERNEL side of how gdb controls a process. > > That'd be me. Feel free to ask any questions you might have. > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 11:26: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 5076D37B400 for ; Wed, 30 Jan 2002 11:26:02 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id B48B310DDF7; Wed, 30 Jan 2002 11:26:00 -0800 (PST) Date: Wed, 30 Jan 2002 11:26:00 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130112600.I13686@elvis.mu.org> References: <3C57C858.5FCC9453@mindspring.com> <21755.1012385956@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <21755.1012385956@critter.freebsd.dk>; from phk@critter.freebsd.dk on Wed, Jan 30, 2002 at 11:19:16AM +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 * Poul-Henning Kamp [020130 02:22] wrote: > In message <3C57C858.5FCC9453@mindspring.com>, Terry Lambert writes: > > Hi Terry, > > I can see from your more and more irrellevant argumentation that > you have realized the battle is lost and now you are just trying > to save face. > > You can save a lot of time for all of us (time which we can then > spend on improving FreeBSD) if you just shut up now. > > Thanks in advance! I must commend you on your ability to turn an otherwise detailed technical discussion into a barrage of personal attacks but I'd like to summarize the actual issues. Removing the __P causes these specific problems: 1) repo bloat. 2) incompatible deltas with other BSDs and older versions of BSD. 3) inability to bootstrap on older platforms with older compilers. Without getting into too much details (which seems to cause headaches) I'm perfectly fine with issue #1, very unhappy with #2 and a bit perterbed about #3. Frankly I wouldn't care either way if the situation hadn't reached this stage. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 11:31:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from glatton.cnchost.com (glatton.cnchost.com [207.155.248.47]) by hub.freebsd.org (Postfix) with ESMTP id 479B637B416 for ; Wed, 30 Jan 2002 11:31:39 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by glatton.cnchost.com id OAA26085; Wed, 30 Jan 2002 14:31:23 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200201301931.OAA26085@glatton.cnchost.com> To: Jordan Hubbard Cc: Terry Lambert , Poul-Henning Kamp , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-reply-to: Your message of "Wed, 30 Jan 2002 09:56:20 PST." <66502.1012413380@winston.freebsd.org> Date: Wed, 30 Jan 2002 11:31:23 -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 > If I had any lingering dowbts about the advisability of going on a > Jihad against __P(), Terry has managed to remove them. I think the > next step is to decide on a schedule for axing them from -current, > before 5.0 comes out. __Please remove them before this argument erupts again! This is a perfect job for those scandinavian axe wielders?!:-) -- bakul PS: BTW, I do believe (and may be agree with Terry?) that function prototypes are entirely unnecessary but *only if* a smarter linker exists that does proper type checking. If Terry wrote such a linker, people would be immensely grateful to him. Similarly, if Terry were to make the changes to the FreeBSD kernel to compile it with TenDRA (and make it work) at least I would be very grateful to him -- I do think relying so much on GCC is a bad idea but I am realistic (and lazy) enough to not want to fix that on my own. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 11:49:14 2002 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 C730637B405 for ; Wed, 30 Jan 2002 11:48:42 -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 GAA01858; Thu, 31 Jan 2002 06:48:33 +1100 Date: Thu, 31 Jan 2002 06:50:09 +1100 (EST) From: Bruce Evans X-X-Sender: To: Takanori Watanabe Cc: Subject: Re: How about removing #ifdef DEV_ISA from autoconf.c In-Reply-To: <200201301732.CAA24465@shidahara1.planet.sci.kobe-u.ac.jp> Message-ID: <20020131064141.X55787-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 31 Jan 2002, Takanori Watanabe wrote: > Hi, I have a patch to be reviewed. > This removes #ifdef DEV_ISA from sys/i386/autoconf.c and > allows to intercept before and after isa_prove_children() executed. > This will enable us statisize isa_probe_children, though what I want to do > is to execute isa_probe_children-like routine in acpi module > after isa_probe_children is exeuted. > > This patch contains patch to i386/i386/autoconf.h and isa/isa_common.c and > new sys/autoconf.h file. > > How do you think about it? The complications to get interrupts enabled at the correct time aren't needed in -current since spl0() has no effect. Interrupts are enabled at incorrect times earlier :-). I guess masking in the ICU prevents serious problems. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 11:51:32 2002 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 C79BA37B400 for ; Wed, 30 Jan 2002 11:51:23 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 42BCA5341; Wed, 30 Jan 2002 20:51:22 +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: Julian Elischer Cc: Doug White , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. References: From: Dag-Erling Smorgrav Date: 30 Jan 2002 20:51:21 +0100 In-Reply-To: Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer writes: > The current debug code seems to call psignal to deliver STOP signals in > order to suspend the process, and the stuff SEF did actually makes teh > processes call msleep(). There are three different debugging interfaces in the kernel: ktrace(2), ptrace(2) and procfs(5). Only procfs(5) (which is used by truss(1) et al.) uses msleep(9); ptrace(2) (which is POSIX, and is what gdb(1) uses) uses psignal(9). The procfs(5) junk is going away as soon as I've finished my ptrace(2)-based version of truss(1), so don't worry about it. > For example: do you want all teh other threads to be suspended, or to be > running? Do you want the UTS to be suspended as well? As far as ptrace(2) is concerned, I think I want all threads to be suspended; ptrace(2) doesn't really support the concept of threads. Our current version of gdb(1) doesn't support threads either (AFAIK), and I don't know if (or how) newer versions of gdb(1) do; we'll cross that bridge when we get there. > I have not completed this work yet.. > but am wondering if you have any violent arguments about what I'm doing.. Not really. It just has to work *somehow*, and I don't really have any opinion on precisely how. The one request i have is that debugging single-threaded processes should work the way it used to (i.e. ptrace(2) should behave the same with single-threaded processes under KSE as it did pre-KSE) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 12:40:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id B515D37B41B for ; Wed, 30 Jan 2002 12:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020130204010.BSOQ10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 30 Jan 2002 20:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA57603; Wed, 30 Jan 2002 12:30:04 -0800 (PST) Date: Wed, 30 Jan 2002 12:30:04 -0800 (PST) From: Julian Elischer To: Dag-Erling Smorgrav Cc: Doug White , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. 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 30 Jan 2002, Dag-Erling Smorgrav wrote: > Julian Elischer writes: > > The current debug code seems to call psignal to deliver STOP signals in > > order to suspend the process, and the stuff SEF did actually makes teh > > processes call msleep(). > > There are three different debugging interfaces in the kernel: > ktrace(2), ptrace(2) and procfs(5). Only procfs(5) (which is used by > truss(1) et al.) uses msleep(9); ptrace(2) (which is POSIX, and is > what gdb(1) uses) uses psignal(9). The procfs(5) junk is going away > as soon as I've finished my ptrace(2)-based version of truss(1), so > don't worry about it. > > > For example: do you want all teh other threads to be suspended, or to be > > running? Do you want the UTS to be suspended as well? > > As far as ptrace(2) is concerned, I think I want all threads to be > suspended; ptrace(2) doesn't really support the concept of threads. > Our current version of gdb(1) doesn't support threads either (AFAIK), > and I don't know if (or how) newer versions of gdb(1) do; we'll cross > that bridge when we get there. > > > I have not completed this work yet.. > > but am wondering if you have any violent arguments about what I'm doing.. > > Not really. It just has to work *somehow*, and I don't really have > any opinion on precisely how. The one request i have is that > debugging single-threaded processes should work the way it used to > (i.e. ptrace(2) should behave the same with single-threaded processes > under KSE as it did pre-KSE) That is my goal, but it may be achieved by using the new call rather than using psignal() to do the work. On your proposed changes, will truss continue to be able to debug linux binaries? will linux-gdb be able to work on FreeBSD? (for Linux binaries?) > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 12:43:56 2002 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 8B71A37B41B for ; Wed, 30 Jan 2002 12:43:53 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id D6D765341; Wed, 30 Jan 2002 21:43:49 +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: Julian Elischer Cc: Doug White , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. References: From: Dag-Erling Smorgrav Date: 30 Jan 2002 21:43:48 +0100 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer writes: > On your proposed changes, will truss continue to be able to debug linux > binaries? Yes. > will linux-gdb be able to work on FreeBSD? (for Linux binaries?) I have received patches for that (adding a ptrace syscall to the linuxulator), but haven't committed them yet. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 13: 6:43 2002 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 B008E37B404 for ; Wed, 30 Jan 2002 13:06:37 -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 g0UL6IJ115910; Wed, 30 Jan 2002 16:06:18 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020130112600.I13686@elvis.mu.org> References: <3C57C858.5FCC9453@mindspring.com> <21755.1012385956@critter.freebsd.dk> <20020130112600.I13686@elvis.mu.org> Date: Wed, 30 Jan 2002 16:06:17 -0500 To: Alfred Perlstein , Poul-Henning Kamp From: Garance A Drosihn Subject: Re: __P macro question Cc: Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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 11:26 AM -0800 1/30/02, Alfred Perlstein wrote: >Removing the __P causes these specific problems: > >1) repo bloat. In the past, we have generated "repo-bloat" just to remove unneeded blanks at the end of lines. If we survived it for that, we can survive it for removing __P()'s. We're constantly doing style fixes which "bloat" the repo. >2) incompatible deltas with other BSDs and older versions of BSD. Note that this is less true than it used to be. For instance, a recent contribution sent to freebsd-standards said: This patch adds the -b and -s options to 'fold'. It's mostly taken from NetBSD but I've hopefully kept it compile-able by K&R compilers. In other words, here's someone who is taking code *from* NetBSD, and *adding* __P()'s to it. Why does he have to add them? Because more than 16 months ago, NetBSD applied an update to 'fold' where the commit message was: (and I quote) Un-__P and ANSIfy. So, while it used to be that there was an advantage in keeping __P()'s so we would remain the same as some other BSD, we now have some new developers who think they should *add* __P()'s to become *incompatible* with another BSD. Clearly we're sending the wrong signal to people who are trying to contribute to FreeBSD. Time has moved on. -- 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 Jan 30 13:30: 6 2002 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 7ABE737B404 for ; Wed, 30 Jan 2002 13:30:04 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0ULT5s71651; Wed, 30 Jan 2002 13:29:05 -0800 (PST) (envelope-from obrien) Date: Wed, 30 Jan 2002 13:29:05 -0800 From: "David O'Brien" To: Garance A Drosihn Cc: Alfred Perlstein , Poul-Henning Kamp , Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130132905.A71599@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <3C57C858.5FCC9453@mindspring.com> <21755.1012385956@critter.freebsd.dk> <20020130112600.I13686@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Wed, Jan 30, 2002 at 04:06:17PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 30, 2002 at 04:06:17PM -0500, Garance A Drosihn wrote: > In the past, we have generated "repo-bloat" just to remove unneeded > blanks at the end of lines. This was not done with the agreement of anyone other than the person that did it. That set of commits is acknowledged by all others to have been WRONG. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 13:54:50 2002 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 AB60537B400 for ; Wed, 30 Jan 2002 13:54:43 -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 g0ULsgo31707; Wed, 30 Jan 2002 14:54:42 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0ULsfx26975; Wed, 30 Jan 2002 14:54:41 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 14:54:24 -0700 (MST) Message-Id: <20020130.145424.00452635.imp@village.org> To: drosih@rpi.edu Cc: deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Garance A Drosihn writes: : I also think that maybe we *do* need a specific code-sweep which does : nothing but (carefully) remove all the __P()'s, if for no other : reason than to avoid seeing this debate again in six to eight months. I'm going through bin right now removing __P() and making the functions have new-style rather than old-style decls. It is a nice little mindless thing to do when to relax and unwind. I plan on committing this this weekend (see below). I've seen nothing so far to tell me not to do it: 1) Repo-bloat: Not an issue. We're going to do this someday, we will have the same amount of repo expansion. Disk is cheap. CVSUP and CTM makes changes like this very pain free. 2) Compat with *BSD: NetBSD is agressively removing __P. OpenBSD is in places and not in others. BSDi doesn't give us code anymore. Diff against Net2 is impossible. This has ceased to be a compelling argument. 3) Compatible with older compilers: unprotoize(1) fixes this for the vanishingly small minority of users that NEED this. We already don't work with non-asni compilers, and the breakage is getting worse as time goes on. Time to clean it up. 4) What about my amiga: gcc works on the amgia. Bootstrap with NetBSD/amiga. I've yet to see a compelling argument against me doing this. You have until Friday to make a compelling case. The time has come for this change. bin gets committed this weekend. I'll post diffs on Friday and commit Sunday/Monday. So far, no one has replied to my other mail that threatened to do this, so I'm taking that as agreement. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 14:14:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 56B0937B402 for ; Wed, 30 Jan 2002 14:14:28 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020130221427.DISO3578.rwcrmhc52.attbi.com@peter3.wemm.org> for ; Wed, 30 Jan 2002 22:14:27 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0UMERs52122 for ; Wed, 30 Jan 2002 14:14:27 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 522493A9A; Wed, 30 Jan 2002 14:14:27 -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: Alfred Perlstein , Poul-Henning Kamp , Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Date: Wed, 30 Jan 2002 14:14:27 -0800 From: Peter Wemm Message-Id: <20020130221427.522493A9A@overcee.wemm.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 Garance A Drosihn wrote: > At 11:26 AM -0800 1/30/02, Alfred Perlstein wrote: > >Removing the __P causes these specific problems: > > > >1) repo bloat. > > In the past, we have generated "repo-bloat" just to remove unneeded > blanks at the end of lines. If we survived it for that, we can > survive it for removing __P()'s. We're constantly doing style fixes > which "bloat" the repo. With my CVS hat on, I am more than happy to say "this is worth it". > >2) incompatible deltas with other BSDs and older versions of BSD. > > Note that this is less true than it used to be. For instance, a recent > contribution sent to freebsd-standards said: > > This patch adds the -b and -s options to 'fold'. It's mostly > taken from NetBSD but I've hopefully kept it compile-able by > K&R compilers. > > In other words, here's someone who is taking code *from* NetBSD, > and *adding* __P()'s to it. Why does he have to add them? Because > more than 16 months ago, NetBSD applied an update to 'fold' where > the commit message was: > (and I quote) > Un-__P and ANSIfy. Yes, NetBSD are actively removing __P() as well. > So, while it used to be that there was an advantage in keeping __P()'s > so we would remain the same as some other BSD, we now have some new > developers who think they should *add* __P()'s to become *incompatible* > with another BSD. Clearly we're sending the wrong signal to people who > are trying to contribute to FreeBSD. Time has moved on. I think if we bite the bullet and do it, it may help act as a catalyst to the other BSD's to do likewise. I believe they have this same argument every 6 months as well and must be about as sick of it as we are. And as a bonus, if this upsets Terry, then that is all the more reason to do it! :-). Death to __P() ! Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 14:24:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 71ED737B402 for ; Wed, 30 Jan 2002 14:24:26 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g0UMOP7O021129; Wed, 30 Jan 2002 17:24:25 -0500 (EST) Date: Wed, 30 Jan 2002 17:24:25 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: <20020130221427.522493A9A@overcee.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 30 Jan 2002, Peter Wemm wrote: > Garance A Drosihn wrote: > I think if we bite the bullet and do it, it may help act as a catalyst to > the other BSD's to do likewise. I believe they have this same argument > every 6 months as well and must be about as sick of it as we are. > > And as a bonus, if this upsets Terry, then that is all the more reason to > do it! :-). So Terry, are you taking note? All you have to do is use reverse logic from now on. And that was probably his intention anyways :) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 14:33:34 2002 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 CE7B137B402; Wed, 30 Jan 2002 14:33:30 -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 g0UMWrd67466; Wed, 30 Jan 2002 14:32:53 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: obrien@FreeBSD.ORG Cc: Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Terry Lambert , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Message from "David O'Brien" of "Wed, 30 Jan 2002 13:29:05 PST." <20020130132905.A71599@dragon.nuxi.com> Date: Wed, 30 Jan 2002 14:32:53 -0800 Message-ID: <67461.1012429973@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 You didn't address any of the other good points he made. > On Wed, Jan 30, 2002 at 04:06:17PM -0500, Garance A Drosihn wrote: > > In the past, we have generated "repo-bloat" just to remove unneeded > > blanks at the end of lines. > > This was not done with the agreement of anyone other than the person that > did it. That set of commits is acknowledged by all others to have been > WRONG. > > > 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 Jan 30 14:36: 6 2002 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 0197C37B402 for ; Wed, 30 Jan 2002 14:36:05 -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 g0UMZNd67496; Wed, 30 Jan 2002 14:35:24 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: "M. Warner Losh" Cc: drosih@rpi.edu, deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Message from "M. Warner Losh" of "Wed, 30 Jan 2002 14:54:24 MST." <20020130.145424.00452635.imp@village.org> Date: Wed, 30 Jan 2002 14:35:23 -0800 Message-ID: <67492.1012430123@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 > Comments? Do it! Do it! I'll bring the weenies and the marshmallows! - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 14:38:52 2002 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 E9A2C37B400 for ; Wed, 30 Jan 2002 14:38:50 -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 g0UMcno31998; Wed, 30 Jan 2002 15:38:49 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0UMcmx27324; Wed, 30 Jan 2002 15:38:48 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 15:38:30 -0700 (MST) Message-Id: <20020130.153830.17592375.imp@village.org> To: jkh@winston.freebsd.org Cc: drosih@rpi.edu, deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <67492.1012430123@winston.freebsd.org> References: <67492.1012430123@winston.freebsd.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <67492.1012430123@winston.freebsd.org> Jordan Hubbard writes: : Do it! Do it! I'll bring the weenies and the marshmallows! Don't forget the chocolate and graham crackers! We'll make smores at BSDcon :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 14:46:13 2002 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 AC2F137B400 for ; Wed, 30 Jan 2002 14:46:09 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0UMjvJ72456; Wed, 30 Jan 2002 14:45:57 -0800 (PST) (envelope-from obrien) Date: Wed, 30 Jan 2002 14:45:57 -0800 From: "David O'Brien" To: Jordan Hubbard Cc: Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Terry Lambert , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130144557.A72262@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <67461.1012429973@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <67461.1012429973@winston.freebsd.org>; from jkh@winston.freebsd.org on Wed, Jan 30, 2002 at 02:32:53PM -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 Wed, Jan 30, 2002 at 02:32:53PM -0800, Jordan Hubbard wrote: > You didn't address any of the other good points he made. I only wanted to squash this point which I felt very much gave the wrong impression and was inaccurate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 14:46:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id BB80C37B404 for ; Wed, 30 Jan 2002 14:46:11 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020130224611.EDFZ3578.rwcrmhc52.attbi.com@peter3.wemm.org> for ; Wed, 30 Jan 2002 22:46:11 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0UMkBs52224 for ; Wed, 30 Jan 2002 14:46:11 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 25D223A9A; Wed, 30 Jan 2002 14:46:11 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: jkh@winston.freebsd.org, drosih@rpi.edu, deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: <20020130.153830.17592375.imp@village.org> Date: Wed, 30 Jan 2002 14:46:11 -0800 From: Peter Wemm Message-Id: <20020130224611.25D223A9A@overcee.wemm.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 "M. Warner Losh" wrote: > In message: <67492.1012430123@winston.freebsd.org> > Jordan Hubbard writes: > : Do it! Do it! I'll bring the weenies and the marshmallows! > > Don't forget the chocolate and graham crackers! We'll make smores at > BSDcon :-) Now there's an idea.. We can present a '__P slayer of the year' award at bsdcon.. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 15: 0:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 7DA4637B404; Wed, 30 Jan 2002 15:00:14 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0UN0Du93769; Wed, 30 Jan 2002 23:00:13 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 8B1A839; Wed, 30 Jan 2002 22:58:06 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g0UMw6E30295; Wed, 30 Jan 2002 22:58:06 GMT (envelope-from mark@grondar.za) Message-Id: <200201302258.g0UMw6E30295@greenpeace.grondar.org> To: obrien@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020130144557.A72262@dragon.nuxi.com> In-Reply-To: <20020130144557.A72262@dragon.nuxi.com> ; from "David O'Brien" "Wed, 30 Jan 2002 14:45:57 PST." Date: Wed, 30 Jan 2002 22:58:01 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Wed, Jan 30, 2002 at 02:32:53PM -0800, Jordan Hubbard wrote: > > You didn't address any of the other good points he made. > > I only wanted to squash this point which I felt very much gave the wrong > impression and was inaccurate. Actually, I think that it is you that is inaccurate. You are referrring to Rod's big whitespace sweep several years ago. While that was unpopular and generally regarded as Bad(tm), that is prehistory as far as most of our committers are concerned. There are a zillion other whitespace and style commits that were perfectly valid and that made the point you are attempting to squash. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 15: 3:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.thehildermans.com (3.wchiv.soho.enteract.com [216.80.72.147]) by hub.freebsd.org (Postfix) with ESMTP id C47BB37B400; Wed, 30 Jan 2002 15:03:01 -0800 (PST) Received: from smtp-gw-4.msn.com ([65.71.104.185]) by mail.thehildermans.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 30 Jan 2002 16:56:47 -0600 Message-ID: <00005bbd61ca$000034a0$00001835@smtp-gw-4.msn.com> To: From: lisa_seemonline2@msn.com Subject: I WANT YOU (FREE) 22358 Date: Wed, 30 Jan 2002 16:59:54 -2000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Reply-To: lis_semeonline888@yahoo.com X-OriginalArrivalTime: 30 Jan 2002 22:56:48.0834 (UTC) FILETIME=[6612FA20:01C1A9E1] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E COME FUCK MY JUICY WET HOLE http://cumageddon.com/?r=first&p=e I WISH THIS BIG DILDO WAS REALLY YOUR HUGE COCK http://hardcorepleasures.net/?r=second&p=e I'M TIRES OF FINGERING MYSELF. I NEED YOUR HUGE COCK NOW. http://smoothai.com/?r=third&p=e F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E F R E E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 16:23:16 2002 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 6826637B425 for ; Wed, 30 Jan 2002 16:23:03 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0V0Mp474175; Wed, 30 Jan 2002 16:22:51 -0800 (PST) (envelope-from obrien) Date: Wed, 30 Jan 2002 16:22:51 -0800 From: "David O'Brien" To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130162251.A74122@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020130144557.A72262@dragon.nuxi.com> <200201302258.g0UMw6E30295@greenpeace.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201302258.g0UMw6E30295@greenpeace.grondar.org>; from mark@grondar.za on Wed, Jan 30, 2002 at 10:58:01PM +0000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 30, 2002 at 10:58:01PM +0000, Mark Murray wrote: > > On Wed, Jan 30, 2002 at 02:32:53PM -0800, Jordan Hubbard wrote: > > > You didn't address any of the other good points he made. > > > > I only wanted to squash this point which I felt very much gave the wrong > > impression and was inaccurate. > > Actually, I think that it is you that is inaccurate. You are > referrring to Rod's big whitespace sweep several years ago. While > that was unpopular and generally regarded as Bad(tm), that is > prehistory as far as most of our committers are concerned. That is the one I was referring too -- that is the one that seemd the author was referring too also as that was the only scrub the entire tree for trailing whitespace w/o any other motivation. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 16:23:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id E552F37B421 for ; Wed, 30 Jan 2002 16:21:22 -0800 (PST) Received: from pool0175.cvx40-bradley.dialup.earthlink.net ([216.244.42.175] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W4yU-0006iM-00; Wed, 30 Jan 2002 16:21:11 -0800 Message-ID: <3C588DCF.AFC83B3@mindspring.com> Date: Wed, 30 Jan 2002 16:20:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Andersson Cc: Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <3C57BED2.E1144F41@mindspring.com> <66467.1012412972@winston.freebsd.org> <20020130175639.GB2437@sushi.sanyusan.se> 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 Anders Andersson wrote: > On Wed, Jan 30, 2002 at 09:49:32AM -0800, Jordan Hubbard wrote: > > Even the NetBSD/amiga port uses gcc. > > NetBSD/amiga just very recently got ANSIfied also :-) I run SVR3.2, the last MMU-less System V, on my 68010 Amiga, not NetBSD, so it's irrelevent whether or not NetBSD/Amiga has been ASNI-fied as to whether or not the FreeBSD source code that I am interested in can be succeffuly compiled with a minimum of effort on platforms other than GCC, or, in the limit, platforms other than *BSD, or platforms other than FreeBSD. This is a code protability and comparative maintenance problem (and, to some, also an aesthetic problem). I consider the __P() to be ugly, but it solves some real problems: 1) Until NetBSD and OpenBSD follow suit, removing __P() will increase cosmetic differences, and therefore will incresingly impede code sharing. 2) The same is true for Darwin/MacOS X and BSD/OS; while it can be argued that BSD/OS is a marginal player at best (though FreeBSD still appears to be in the process of porting code from it), the same argument can not be made of Darwin/MacOS X. 3) I realize that the post that started this thread was by an Apple employee who could not see the use of the __P() construct, and had been referred to this forum by Jordan, and that this argues that the Darwin/MacOS X camp would be happy to go along with removing the __P(), if that were the consensus for the code involved. However, we should note that the MacOS UDF FS implementeation depends on having both block and character devices, so it is already a divergent code base, and we should be mindful of that fact. The bottom line is that the policy is *already* to not put it in to new code, and to use prototypes instead, rendering new code non-portable to older platforms and uncompilable by older tool chains. While I may disagree with this policy strenuously, it is the stated policy of the FreeBSD Project. People will remember that I noted that this was the policy in my very first posting in this thread. With that in mind, we are now talking about the liberal interpretation of that policy when visiting code that is not new, and making that change to code shared with the other *BSD variants, OpenBSD, NetBSD, Darwin/MacOS X, and BSD/OS. This liberal interpretation has been made by some to justify an increase n the cosmetic changes. While I agree that it improves the aesthetics of the code, I also believe that it damages both portability, and the ability to track differences between the code bases. I am also probably not alone in being a BSD person who would be just as happy with the FreeBSD, NetBSD, and OpenBSD code bases moving toward unification, even if such is more than a decade away, and with the Darwin/MacOS X code base being even more literally derived from the FreeBSD code base. I believe that removing the __P() macro -- indeed, removing all of the uses of the cdefs.h header file at all -- must, minimally, be done with the consensus of the NetBSD and OpenBSD and Darwin/MacOS X code bases to do the same. As an intentionally marginalized player, waiting for BSD/OS to agree to follow suit is not necessarily a requirement, but it is, to my mind, desirable to solicit such participation as possible from that camp, should the consensus decision be made by the other *BSD to go in that direction. I fear that yielding to full dependency on a single tool chain is not a good idea for the long term. Putting aside the argument that the next version of the license could be modified to apply to the GCC components that are liked into every program, thus causing a monumental problem going forward (Brett Glass, by advocating this position has thereby painted it as alarmist), there is another problem: the GCC does not generate as good code as the commercial compilers for non-Intel platforms. Indeed, even for Intel platforms, the "how to compile code for the Pentium 4" document reads as a litany of why one should not build their compiler in the way that GCC has built its compiler. While we may now argue that "the Alpha platform is dead", and justify in our own minds thereby the idea that GCC dependence is acceptable for that platform, that does not fix the known problems with GCC code generation for the IA64, Pentium 4, or SPARC processors, which we can not so quickly dismiss. As we have learned -- or should have learned -- diversity in the OS ecosystem is a positive influence on the code: it is better for having a Linux, a UnixWare, a Solaris, and, yes, a Windows NT. Artificially limiting code diversity in the realm of compilers seems, to me, an obvious mistake. It is my wish that, if nothing else be taken from this discussion, that people at least take this: The total removal of __P() or cdefs.h itself is not a decision which can be made in isolation by FreeBSD, with disregard for the other *BSD communities, and without a consensus that all will make the change at around the same time, if the change is in fact inevitable. Even if I personally believe such a decision to be misguided by youth and a zeal to discard inconvenient history, it is at least better that all the code move or none of the code move, than it is that some moves and some does not. Thank you, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 16:27:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 85A4737B405 for ; Wed, 30 Jan 2002 16:27:48 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 5E10010DDFB; Wed, 30 Jan 2002 16:27:48 -0800 (PST) Date: Wed, 30 Jan 2002 16:27:48 -0800 From: Alfred Perlstein To: Daniel Eischen Cc: Peter Wemm , Garance A Drosihn , Poul-Henning Kamp , Terry Lambert , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130162748.S13686@elvis.mu.org> References: <20020130221427.522493A9A@overcee.wemm.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 eischen@pcnet1.pcnet.com on Wed, Jan 30, 2002 at 05:24:25PM -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 * Daniel Eischen [020130 14:24] wrote: > On Wed, 30 Jan 2002, Peter Wemm wrote: > > Garance A Drosihn wrote: > > I think if we bite the bullet and do it, it may help act as a catalyst to > > the other BSD's to do likewise. I believe they have this same argument > > every 6 months as well and must be about as sick of it as we are. > > > > And as a bonus, if this upsets Terry, then that is all the more reason to > > do it! :-). > > So Terry, are you taking note? All you have to do is use reverse > logic from now on. And that was probably his intention anyways :) Hmmm.... I wonder if Terry is a Spaniard? Maybe he poisoned both glasses? :) -- -Alfred Perlstein [alfred@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 Jan 30 16:34: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 4CDDD37B419 for ; Wed, 30 Jan 2002 16:33:59 -0800 (PST) Received: from pool0175.cvx40-bradley.dialup.earthlink.net ([216.244.42.175] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W5AZ-00079a-00; Wed, 30 Jan 2002 16:33:40 -0800 Message-ID: <3C5890DD.A21FEEE2@mindspring.com> Date: Wed, 30 Jan 2002 16:33:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > And as a bonus, if this upsets Terry, then that is all the more reason to > > do it! :-). > > So Terry, are you taking note? All you have to do is use reverse > logic from now on. And that was probably his intention anyways :) What makes everyone think I am not using reverse psychology now? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 16:35:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 4855B37B404 for ; Wed, 30 Jan 2002 16:35:28 -0800 (PST) Received: from pool0175.cvx40-bradley.dialup.earthlink.net ([216.244.42.175] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W5C3-0001Hc-00; Wed, 30 Jan 2002 16:35:11 -0800 Message-ID: <3C589138.F82616FD@mindspring.com> Date: Wed, 30 Jan 2002 16:35:04 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Daniel Eischen , Peter Wemm , Garance A Drosihn , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020130221427.522493A9A@overcee.wemm.org> <20020130162748.S13686@elvis.mu.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 Alfred Perlstein wrote: > > > And as a bonus, if this upsets Terry, then that is all the more reason to > > > do it! :-). > > > > So Terry, are you taking note? All you have to do is use reverse > > logic from now on. And that was probably his intention anyways :) > > Hmmm.... I wonder if Terry is a Spaniard? Maybe he poisoned both > glasses? :) Inconceivable. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 16:54:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 77C5637B404 for ; Wed, 30 Jan 2002 16:54:16 -0800 (PST) Received: from pool0175.cvx40-bradley.dialup.earthlink.net ([216.244.42.175] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W5UJ-0000Yo-00; Wed, 30 Jan 2002 16:54:03 -0800 Message-ID: <3C5895A5.D65A3ADB@mindspring.com> Date: Wed, 30 Jan 2002 16:53:57 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <63609.1012386890@axl.seasidesoftware.co.za> 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 M. Warner Losh wrote: > 2) Compat with *BSD: NetBSD is agressively removing __P. OpenBSD is > in places and not in others. BSDi doesn't give us code anymore. > Diff against Net2 is impossible. This has ceased to be a > compelling argument. I guess you aren't an embedded systems vendor with a version of FreeBSD imported into their CVS repository, who needs to be able to track bug fixes, but not large architectural changes byt using "diff" instead of "cvs diff". > 4) What about my amiga: gcc works on the amgia. Bootstrap with > NetBSD/amiga. This particular case refers to an Amiga 1000 with a 68010, which is not capable of running NetBSD. Yes, I agree that it is not a compelling argument, it was intended to be a member of a class of arguments. So even if it is easy to invalidate the Amiga argument itself, it says nothing about the class. > 2) Compat with *BSD: NetBSD is agressively removing __P. > OpenBSD is in places and not in others. BSDi doesn't > give us code anymore. Diff against Net2 is impossible. > This has ceased to be a compelling argument. I wish you would at least gain the consensus of the OpenBSD and NetBSD projects, as well. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 16:55:27 2002 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 2783437B400; Wed, 30 Jan 2002 16:55:24 -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 g0V0tKJ123756; Wed, 30 Jan 2002 19:55:20 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020130144557.A72262@dragon.nuxi.com> References: <67461.1012429973@winston.freebsd.org> <20020130144557.A72262@dragon.nuxi.com> Date: Wed, 30 Jan 2002 19:55:18 -0500 To: obrien@FreeBSD.ORG, Jordan Hubbard From: Garance A Drosihn Subject: Re: __P macro question Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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 2:45 PM -0800 1/30/02, David O'Brien wrote: >On Wed, Jan 30, 2002, Jordan Hubbard wrote: > > You didn't address any of the other good points he made. > >I only wanted to squash this point which I felt very much gave >the wrong impression and was inaccurate. Yeah, my reference to the "blanks update" probably didn't come across quite the way I intended it to. I don't blame David for wanting to comment on that. I was never particularly thrilled with the "blanks update" itself, I just meant it as the most-extreme case of repo-bloat. Whatever you might think about the "blanks update", it's clear that the freebsd project was not crushed by the bloat in the cvs repo. My thought is that a change is either good or it's bad. We would not and should not avoid any GoodUpdate (tm) due to "repo-bloat". -- 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 Jan 30 16:58: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id CFAA137B419 for ; Wed, 30 Jan 2002 16:58:04 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020131005804.IVGE10199.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Thu, 31 Jan 2002 00:58:04 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0V0w4s52694 for ; Wed, 30 Jan 2002 16:58:04 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 00B063A9A; Wed, 30 Jan 2002 16:58:03 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Anders Andersson , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: <3C588DCF.AFC83B3@mindspring.com> Date: Wed, 30 Jan 2002 16:58:03 -0800 From: Peter Wemm Message-Id: <20020131005804.00B063A9A@overcee.wemm.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 Terry Lambert wrote: > Anders Andersson wrote: > > On Wed, Jan 30, 2002 at 09:49:32AM -0800, Jordan Hubbard wrote: > > > Even the NetBSD/amiga port uses gcc. > > > > NetBSD/amiga just very recently got ANSIfied also :-) [..] > I consider the __P() to be ugly, but it solves some real > problems: > > 1) Until NetBSD and OpenBSD follow suit, removing > __P() will increase cosmetic differences, and > therefore will incresingly impede code sharing. In case you didn't notice, this rant you posted is in a thread that mentions that NetBSD *is* agressively removing __P() and OpenBSD appear to be as well. > The bottom line is that the policy is *already* to not put > it in to new code, and to use prototypes instead, rendering > new code non-portable to older platforms and uncompilable > by older tool chains. > > While I may disagree with this policy strenuously, it is > the stated policy of the FreeBSD Project. I'm sure that after reading this thread from hell for the 20th time and Terry's 700th rant on the subject that the policy will be changed ASAP. Policy is easy to change, especially if it'll put this subject to rest at long last before we have another 5 iterations of over the next few years. The bottom line is that the effort to port gcc to an arch that only has a K&R compiler is far more productive than trying to get our tree to build on a K&R-only compiler. Nobody in their right mind is going to run FreeBSD-5.x on a 6809 or a Z80 or a 68010. The least of their problems is the compiler. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 17:14: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 611CD37B417 for ; Wed, 30 Jan 2002 17:14:02 -0800 (PST) Received: from pool0175.cvx40-bradley.dialup.earthlink.net ([216.244.42.175] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W5nJ-0004bD-00; Wed, 30 Jan 2002 17:13:42 -0800 Message-ID: <3C589A3F.10F18882@mindspring.com> Date: Wed, 30 Jan 2002 17:13:35 -0800 From: Terry Lambert 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 , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020130221427.522493A9A@overcee.wemm.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 Peter Wemm wrote: > In case you didn't notice, this rant you posted is in a thread > that mentions that NetBSD *is* agressively removing __P() and OpenBSD > appear to be as well. I want the decision to be intentional, not simply because of "herd instinct". > The bottom line is that the effort to port gcc to an arch that only has a > K&R compiler is far more productive than trying to get our tree to build > on a K&R-only compiler. The cost to doing this is: 1) You risk becoming the compiler maintainer for 2 years, in order to comply with the license. 2) It is another barrier to using BSD code. 3) The GCC compiler is sub-par on many architectures. > Nobody in their right mind is going to run FreeBSD-5.x on a 6809 or > a Z80 or a 68010. The least of their problems is the compiler. I hope your misunderstanding here is intentional. I am not talking about running the full FreeBSD-5.x on a 68010, I am talking about using portions of the code as a reference implementation. For example, taking the TCP/IP stack by itself, with all the DOS attack hardening and other hardenening, and using it in a system other than FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 17:26:52 2002 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 05A8637B416 for ; Wed, 30 Jan 2002 17:26:48 -0800 (PST) Received: from hades.hell.gr (patr530-a064.otenet.gr [212.205.215.64]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g0V1QG7q018626; Thu, 31 Jan 2002 03:26:17 +0200 (EET) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id g0V1QE062218; Thu, 31 Jan 2002 03:26:14 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Thu, 31 Jan 2002 03:26:14 +0200 From: Giorgos Keramidas To: Terry Lambert Cc: Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@freebsd.org Subject: Re: __P macro question Message-ID: <20020131012614.GA61488@hades.hell.gr> References: <20020130221427.522493A9A@overcee.wemm.org> <3C589A3F.10F18882@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C589A3F.10F18882@mindspring.com> User-Agent: Mutt/1.3.25i Sender: owner-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 2002-01-30 17:13, Terry Lambert wrote: > Peter Wemm wrote: > > > Nobody in their right mind is going to run FreeBSD-5.x on a 6809 or > > a Z80 or a 68010. The least of their problems is the compiler. > > I hope your misunderstanding here is intentional. > > I am not talking about running the full FreeBSD-5.x on a > 68010, I am talking about using portions of the code as a > reference implementation. > > For example, taking the TCP/IP stack by itself, with all > the DOS attack hardening and other hardenening, and using > it in a system other than FreeBSD. I'm afraid that even in that area, the changes and differences between the original Net/[123] code and the -CURRENT trees of BSDs are far more than a simple __P() change. One who has to maintain the changes done already in other parts and subsystems of the kernel that the TCP stack changes depend on, has a lot more work to do. I somehow fail to see the point of all this... - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 17:32: 1 2002 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 2E0CE37B402 for ; Wed, 30 Jan 2002 17:31:58 -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 g0V1Vuo32737; Wed, 30 Jan 2002 18:31:56 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0V1Vtx28349; Wed, 30 Jan 2002 18:31:55 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 18:31:39 -0700 (MST) Message-Id: <20020130.183139.84750367.imp@village.org> To: tlambert2@mindspring.com Cc: deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <3C5895A5.D65A3ADB@mindspring.com> References: <63609.1012386890@axl.seasidesoftware.co.za> <3C5895A5.D65A3ADB@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <3C5895A5.D65A3ADB@mindspring.com> Terry Lambert writes: : : M. Warner Losh wrote: : > 2) Compat with *BSD: NetBSD is agressively removing __P. OpenBSD is : > in places and not in others. BSDi doesn't give us code anymore. : > Diff against Net2 is impossible. This has ceased to be a : > compelling argument. : : I guess you aren't an embedded systems vendor with a : version of FreeBSD imported into their CVS repository, : who needs to be able to track bug fixes, but not large : architectural changes byt using "diff" instead of : "cvs diff". I am an embedded systems vendor. A new version of ssh or groff is much more of a pita than this change because that has files added/deleted from the tree. The worst that can happen with this change is minor conflicts... I don't think it will be an issue. : > 4) What about my amiga: gcc works on the amgia. Bootstrap with : > NetBSD/amiga. : : This particular case refers to an Amiga 1000 with a 68010, : which is not capable of running NetBSD. Yes, I agree that : it is not a compelling argument, it was intended to be a : member of a class of arguments. So even if it is easy to : invalidate the Amiga argument itself, it says nothing about : the class. Cross compilers exist. unprotoize exists for use with K&R compilers. However, K&R compilers have several features of modern C missing. 1) no long long support 2) no void support 3) no const support 4) no long double support 5) "string " "concat" doesn't work 6) All struct member names are from one global name space 7) Many small, but potentially significant minor changes in semantics make it difficult to ensure that the code will work in a K&R world. 8) Library support is radically different in K&R. free(NULL) was fatal, not explicitly allowed. Different ways of doing tty manip, etc are all barriers to entry short of a full port. 9) no support for prototypes ... FreeBSD uses these all over the place, making a port of most of the FreeBSD source to a K&R compiler hard. The FreeBSD doesn't support K&R compilers, so it shouldn't pretend to do so. : I wish you would at least gain the consensus of the OpenBSD : and NetBSD projects, as well. NetBSD already is agressively moving to pure ANSI C. As near as I can tell, OpenBSD hasn't made up its mind yet. Maybe this will help them. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 17:40:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 4361B37B400 for ; Wed, 30 Jan 2002 17:40:55 -0800 (PST) Received: from pool0175.cvx40-bradley.dialup.earthlink.net ([216.244.42.175] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W6D8-0004ZR-00; Wed, 30 Jan 2002 17:40:22 -0800 Message-ID: <3C58A07A.49792083@mindspring.com> Date: Wed, 30 Jan 2002 17:40:10 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giorgos Keramidas Cc: Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@freebsd.org Subject: Re: __P macro question References: <20020130221427.522493A9A@overcee.wemm.org> <3C589A3F.10F18882@mindspring.com> <20020131012614.GA61488@hades.hell.gr> 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 Giorgos Keramidas wrote: > > For example, taking the TCP/IP stack by itself, with all > > the DOS attack hardening and other hardenening, and using > > it in a system other than FreeBSD. > > I'm afraid that even in that area, the changes and differences between > the original Net/[123] code and the -CURRENT trees of BSDs are far > more than a simple __P() change. One who has to maintain the changes > done already in other parts and subsystems of the kernel that the TCP > stack changes depend on, has a lot more work to do. > > I somehow fail to see the point of all this... The point is that if I were wanting to use a freely available reference implementation of TCP/IP, right now I would prefer to use FreeBSDs implementation, so long as it remains portable to my platform. As soon as it is no longer portable to my platform (I really could care less about deltas between "Net/[123]" for the sake of this argument), it becomes less useful as a reference implementation. One of the *points* to using Open Source code at all is to reduce your maintenance burden and bootstrap overhead. While it is valid to state that there is other work to do, that other work is unavoidable. We are talking about increasing the avoidable work here. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 18:20:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id A69BA37B404 for ; Wed, 30 Jan 2002 18:19:59 -0800 (PST) Received: from pool0175.cvx40-bradley.dialup.earthlink.net ([216.244.42.175] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16W6pN-0000Bx-00; Wed, 30 Jan 2002 18:19:54 -0800 Message-ID: <3C58A9C2.6890CB19@mindspring.com> Date: Wed, 30 Jan 2002 18:19:46 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question References: <63609.1012386890@axl.seasidesoftware.co.za> <3C5895A5.D65A3ADB@mindspring.com> <20020130.183139.84750367.imp@village.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 "M. Warner Losh" wrote: > I am an embedded systems vendor. A new version of ssh or groff is > much more of a pita than this change because that has files > added/deleted from the tree. The worst that can happen with this > change is minor conflicts... I don't think it will be an issue. This is the "it hurts more if I am stabbed in the liver than if I stub my toe, so I'm not going to avoid stubbing my toe" argument. 8-). > Cross compilers exist. unprotoize exists for use with K&R compilers. Yesm, I agree. These are toes stubbed on the barrier to entry: it doesn't prevent you from entering, but it is pain that you would not have otherwise had to endure. > However, K&R compilers have several features of modern C missing. > 1) no long long support Questionable value on 32 bit architectures. > 2) no void support > 3) no const support These are for the optimization convenience of the compiler; older compilers didn't have them, and cdefs.h "zaps" them out, along with "volatile". > 4) no long double support See #1. > 5) "string " "concat" doesn't work I don't know how concerned I am about this; how often is this used in FreeBSD source code? > 6) All struct member names are from one global name space Yes. This is a protability issue, like knowing that you can't use "register" within scopes inferior to function level scoping, and still compile on certain compilers and have correct code generated, or knowing that a negative pointer reference on an utho variable pointer to a statically allocated area may not generate the correct code, e.g.: char *p = "Hello World" + 6; printf( "p = '%s'\n", p); printf( "p-6 = '%s'\n", p - 6); This is why stat structure members have "st_" prefixes on their members. It's interesting to note that POSIX has writ this convention into standard for well known interfaces. > 7) Many small, but potentially significant minor changes > in semantics make it difficult to ensure that the code > will work in a K&R world. Actually, going the other way is harder. A K&R compiler will generate working code for ANSI C code, stripped of the qualifiers used to make the compiler writer's life easier, but an ANSI C compiler will generate incorrect code in a number of cases for historically correct code (e.g. register optimization of a global loop control variable that is modified from a signal handler, causing the code to loop forever, unless the volatile keyword is used on the variable -- also a convenience for the compiler writer). In general, I would say that ANSI C adds semantics for the code to give hints to the compiler about invalid assumptions that the compiler would otherwise be permitted to make. This permits ANSI C compilers to generate better code without a lot of additional effort on the part of the compiler writers being required to employ these optimizations. So, in general, the main worry is K&R C code that breaks when compiled with ANSI C compilers, rather than the other way around (assuming cdefs.h strips the unsupported keywords). > 8) Library support is radically different in K&R. free(NULL) > was fatal, not explicitly allowed. Different ways of > doing tty manip, etc are all barriers to entry short of > a full port. Yes, there are API differences over time. Linking the compiler technology to the time is not completely valid in this case, however. [ As an historical note, I'll point out that "free(NULL)" was an explicit invocation of the coeslescing of free space according to "The C Programming Language", and that tty manipulation can be abstracted down to 6 system interfaces, and made relatively very portable; I wrote code that ran on approximately 140 vendor implementations of UNIX, with only 3 variant files. ] > 9) no support for prototypes This is really a language problem. Prototypes were added to C for 5 primary reasons: 1) Avoid the sign extension to "int" on the stack 2) Allow standardized passing of larger-than-int values 3) So that C programs could be compiled with C++ compilers, which were considered to be the future technology path for C evolution 4) To do usage checking which could just as easily been done at link-time, if there had been symbol attribution in the object file (i.e. to get the benefit of the checking without changing the object file format). 5) To avoid the "glue code" generation that would have been required to achieve these, if the glue code generation at link time had been used in order to let the link go through (i.e. as a latency fix for bsd programmers, that didn't result in executable size bloat). > ... > > FreeBSD uses these all over the place, making a port of most of the > FreeBSD source to a K&R compiler hard. The FreeBSD doesn't support > K&R compilers, so it shouldn't pretend to do so. I guess I have to refer back to my original posting again, then, to note that the FreeBSD policy is to introduce the incompatabilities in new code. The issue, once again, is not necessarily about supporting K&R compilers with new code. It's about gratuitous changes. If you could get agreement from the NetBSD and OpenBSD core teams that conversion was NetBSD and OpenBSD policy, and made it FreeBSD policy, then most of the arguments against it as a gratuitous change devolve into historical reference for substantive changes being more difficult, and to the (usually commercial) non-project use of the code. I think we could eat that, even if some of us didn't like the taste. > : I wish you would at least gain the consensus of the OpenBSD > : and NetBSD projects, as well. > > NetBSD already is agressively moving to pure ANSI C. As near as I can > tell, OpenBSD hasn't made up its mind yet. Maybe this will help them. What does the NetBSD core team say? I'm not talking about commits, which like Rod Grimes' whitespace patch, might be backed out by the-powers-that-be, I'm asking about what the-powers-that-be have to say about it. I think a cross-BSD agreement to change (or not) would be a good thing. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 18:46: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pr0n.kutulu.org (pr0n.kutulu.org [151.196.107.157]) by hub.freebsd.org (Postfix) with ESMTP id 7D46537B405 for ; Wed, 30 Jan 2002 18:46:01 -0800 (PST) Received: from cc191573g (beta.kutulu.org [68.50.102.129]) by pr0n.kutulu.org (Postfix) with SMTP id A6E074D; Wed, 30 Jan 2002 21:48:32 -0500 (EST) Message-ID: <019701c1aa19$27b2fb30$81663244@longhill1.md.home.com> From: "Kutulu" To: "Terry Lambert" , "Anders Andersson" Cc: "Jordan Hubbard" , "Dallas De Atley" , References: <3C57BED2.E1144F41@mindspring.com> <66467.1012412972@winston.freebsd.org> <20020130175639.GB2437@sushi.sanyusan.se> <3C588DCF.AFC83B3@mindspring.com> Subject: Re: __P macro question Date: Wed, 30 Jan 2002 21:35:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.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 From: "Terry Lambert" Sent: Wednesday, January 30, 2002 4:20 PM > The bottom line is that the policy is *already* to not put > it in to new code, and to use prototypes instead, rendering > new code non-portable to older platforms and uncompilable > by older tool chains. > I fear that yielding to full dependency on a single tool > chain is not a good idea for the long term. I am by no means a FreeBSd hacker, just an interested observer, so please don't take this question as anything other than curiosity. I generally understand the reason for/against using the prototype-hiding macro. However, your (Terry's) position repeatedly argues for keeping this in code to avoid being dependant on GCC. Is GCC the only UNIX compiler that can compile code with prototypes? Isn't that an ANSI standard requirement, not a gcc-ism? I have never used any compiler other than gcc and some Borland stuff, so I really don't know the answer, but it seems to me that anyone, like myself, coming into UNIX development at this point in time would expect *some* ANSI-enabled compiler to be around for any platform, wether the GNU people wrote it or not. Is this a stupid assumption to make? --Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 19: 3:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 4EFAB37B400 for ; Wed, 30 Jan 2002 19:03:35 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020131030329.MHUA10199.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Thu, 31 Jan 2002 03:03:29 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0V33Ts53104 for ; Wed, 30 Jan 2002 19:03:29 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 2E01C3A9A; Wed, 30 Jan 2002 19:03:29 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Giorgos Keramidas , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@freebsd.org Subject: Re: __P macro question In-Reply-To: <3C58A07A.49792083@mindspring.com> Date: Wed, 30 Jan 2002 19:03:29 -0800 From: Peter Wemm Message-Id: <20020131030329.2E01C3A9A@overcee.wemm.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 Terry Lambert wrote: > Giorgos Keramidas wrote: > > > For example, taking the TCP/IP stack by itself, with all > > > the DOS attack hardening and other hardenening, and using > > > it in a system other than FreeBSD. > > > > I'm afraid that even in that area, the changes and differences between > > the original Net/[123] code and the -CURRENT trees of BSDs are far > > more than a simple __P() change. One who has to maintain the changes > > done already in other parts and subsystems of the kernel that the TCP > > stack changes depend on, has a lot more work to do. > > > > I somehow fail to see the point of all this... > > The point is that if I were wanting to use a freely > available reference implementation of TCP/IP, right > now I would prefer to use FreeBSDs implementation, so > long as it remains portable to my platform. Well, our network stack is nowhere near K&R compliant, not by a million miles. So forget that line of the argument. > One of the *points* to using Open Source code at all > is to reduce your maintenance burden and bootstrap > overhead. Ahh you see, that is a problem. The FreeBSD project's purpose is to make a viable free operating system, not to bend over backwards to make it convenient for other vendors who want to take our code and run it on a cpu from 1974 with a compiler from 1973. We the project have no such obligations. *If* our code is useful, then go for your life. If not, then too bad. We have no obligation to *support* some arbitary fictitious vendor who is so damn cheap that they want to save 3 seconds of engineer time to run unprotoize on components of our source tree. > While it is valid to state that there is other work to > do, that other work is unavoidable. We are talking > about increasing the avoidable work here. If you add up the number of developer hours that have been wasted over the last 8 to 10 years on this subject and reapply it to kernel development, we'd have *finished* SMPng by now. As far as I'm concerned: Kill it, get it over with, and rid ourselves of the ongoing drain of developer time that you seem to enjoy contributing to. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 19:15: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 8D88B37B405 for ; Wed, 30 Jan 2002 19:15:04 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020131031504.HYBB5382.rwcrmhc54.attbi.com@peter3.wemm.org> for ; Thu, 31 Jan 2002 03:15:04 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0V2pLs53042 for ; Wed, 30 Jan 2002 18:51:21 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 308C13A9A; Wed, 30 Jan 2002 18:51:21 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@freebsd.org Subject: Re: __P macro question In-Reply-To: <3C589A3F.10F18882@mindspring.com> Date: Wed, 30 Jan 2002 18:51:21 -0800 From: Peter Wemm Message-Id: <20020131025121.308C13A9A@overcee.wemm.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 Terry Lambert wrote: > Peter Wemm wrote: > > In case you didn't notice, this rant you posted is in a thread > > that mentions that NetBSD *is* agressively removing __P() and OpenBSD > > appear to be as well. > > I want the decision to be intentional, not simply because > of "herd instinct". Well, it is looking pretty intentional so far to me. > > The bottom line is that the effort to port gcc to an arch that only has a > > K&R compiler is far more productive than trying to get our tree to build > > on a K&R-only compiler. > > The cost to doing this is: > > 1) You risk becoming the compiler maintainer for 2 > years, in order to comply with the license. Nope. Nobody says you have to maintain it. Besides, FreeBSD isn't going to run on any system so obscure that it wont have some sort of ansi compiler available any time in the forseeable future. > 2) It is another barrier to using BSD code. So? versus what? GNU code which is also ANSI? > 3) The GCC compiler is sub-par on many architectures. It tends to work better on older platforms than newer ones. > > Nobody in their right mind is going to run FreeBSD-5.x on a 6809 or > > a Z80 or a 68010. The least of their problems is the compiler. > > I hope your misunderstanding here is intentional. > > I am not talking about running the full FreeBSD-5.x on a > 68010, I am talking about using portions of the code as a > reference implementation. No, I am not misunderstanding it. We, the project, are making decisions about what is good for he project, not what is good for what Terry Lambert dreams about doing one weekend to see if he can get src/bin/ls to compile standalone on his TRS-80 6809 system running bcc. If eliminating the use of __P() in our code means that we dont need to spend developer-weeks of time every 6 months, then it is damn well worth it. > For example, taking the TCP/IP stack by itself, with all > the DOS attack hardening and other hardenening, and using > it in a system other than FreeBSD. I hope you noticed that all that code is nearly pure ANSI. ... static void syncache_drop(struct syncache *, struct syncache_head *); static void syncache_free(struct syncache *); ... static void syncache_free(struct syncache *sc) { ... peter@daintree[6:50pm]~src/sys/netinet-102> grep __P tcp_syncache.c peter@daintree[6:51pm]~src/sys/netinet-103> *Bad* example! Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 19:21:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id D468237B404 for ; Wed, 30 Jan 2002 19:21:13 -0800 (PST) Received: from pool0224.cvx40-bradley.dialup.earthlink.net ([216.244.42.224] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16W7mc-0000WF-00; Wed, 30 Jan 2002 19:21:06 -0800 Message-ID: <3C58B817.CD4BA183@mindspring.com> Date: Wed, 30 Jan 2002 19:20:55 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kutulu Cc: Anders Andersson , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <3C57BED2.E1144F41@mindspring.com> <66467.1012412972@winston.freebsd.org> <20020130175639.GB2437@sushi.sanyusan.se> <3C588DCF.AFC83B3@mindspring.com> <019701c1aa19$27b2fb30$81663244@longhill1.md.home.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 Kutulu wrote: > I generally understand the reason for/against using the prototype-hiding > macro. However, your (Terry's) position repeatedly argues for keeping this > in code to avoid being dependant on GCC. This is not accurate. I am arguing that the code should be portable to tool chains other than the FreeeBSD i386 port tool chain. This happens to be GCC. So, really, there are two issues: 1) I would like to avoid dependence on needing an ANSI C compiler, because I like running interoperable code everywhere I can; if I have something one place, I want it every place (bash, emacs, and NetBSD users should identify with this). I think the handwriting is on the wall on this one, and non-ANSI compiler support is going to be killed; however, I feel compelled to point out the flaws in the arguments for this, which are the following false assumptions: o GCC runs everywhere, and it's easy to port where it doesn't [this adds to the cost of any project] o There is no ongoing cost to maintaining a port of GCC to a new platform, so if there is not ANSI compiler, there's GCC [there is a two year source availability clause in the GPL that can only be satisfied by a source escrow, to meet the terms of the license, should the GCC people not integrate your port into their distribution] 2) I would like to avoid the dependency on the GCC compiler, itself, for several reasons: o As a matter of general principle o As a "CYA" on the "or any future version of this license" clause under which the code was obtained. o The code generated by the GCC compiler is not as good as that available in other compilers, particularly for the P4, Alpha, PPC, and SPARC, all of which are more important than the i386, for which support has been dropped in GENERIC, and is only available through recompilation with alternate configuration options o Use of GCC'isms will result in naeive programmers writing code that can not be compiled with even other ANSI-C standard compilers (e.g. TenDRA, the Compaq Alpha compiler, the SunSoft SPARC compiler, the Intel IA32/IA64 compilers, etc.), in much the same way that use of "bash" and "GNU make" on Linux has resulted in shell scripts and Makefiles which are not portable to other platforms... and worse, tools that automatically generate these scripts and Makefiles, not knowing that their output amplification effect will result in widescale problems. I feel compelled to also point out the flaws in the "All the world is GCC" arguments for this, which are the following false assumptions: o GCC is available everywhere [it's not] o The code will only ever be used in the context of FreeBSD itself, not a reference for another platform [this is a really bogus assumption, and exposes the heart of why FreeBSD is distributed under the BSD license rather than the GPL: to make its source code useful as a reference implementation in other than FreeBSD] o Use of GCC is preferrable [as pointed out above, the code generation is non-optimal] o There is no cost to using GCC [also, noted above] Here is Intel's paper on "software optimization techniques and tools to achieve leading-edge performance on current and future generations of the IA-32 high-performance processors"... in other words, this information will continue to be valid going forward: http://developer.intel.com/design/pentium4/papers/249438.htm A short summary: Don't do what GCC does > Is GCC the only UNIX compiler that can compile code with prototypes? > Isn't that an ANSI standard requirement, not a gcc-ism? I have never > used any compiler other than gcc and some Borland stuff, so I really > don't know the answer, but it seems to me that anyone, like myself, > coming into UNIX development at this point in time would expect *some* > ANSI-enabled compiler to be around for any platform, wether the GNU > people wrote it or not. > > Is this a stupid assumption to make? For certain problem domains, it is an incorrect assumption; the problems are deeper than they are being portrayed by some. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 19:40:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 8E66237B402 for ; Wed, 30 Jan 2002 19:40:21 -0800 (PST) Received: from pool0224.cvx40-bradley.dialup.earthlink.net ([216.244.42.224] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W856-0003FN-00; Wed, 30 Jan 2002 19:40:13 -0800 Message-ID: <3C58BC92.44F5ED37@mindspring.com> Date: Wed, 30 Jan 2002 19:40:02 -0800 From: Terry Lambert 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 , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020131025121.308C13A9A@overcee.wemm.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 Peter Wemm wrote: > > 1) You risk becoming the compiler maintainer for 2 > > years, in order to comply with the license. > > Nope. Nobody says you have to maintain it. Besides, FreeBSD isn't going > to run on any system so obscure that it wont have some sort of ansi > compiler available any time in the forseeable future. Oops; three years, not two. Please read section 3(b) of the GPL at: http://www.gnu.org/licenses/gpl.html > > 2) It is another barrier to using BSD code. > > So? So it is a barrier to contributing to a BSD project as a means of promoting progress in the art and science, and, in general, for betterment of the human condition. > versus what? GNU code which is also ANSI? Versus anything. The GNU code is already irrelevent, in that it classifies some people as being less deserving than others, and so it is not in the same category, since it has little or no utility as a reference implementation for other than interoperability testing. > > 3) The GCC compiler is sub-par on many architectures. > > It tends to work better on older platforms than newer ones. How will this get the same P4 instruction pipelining optimization performance that the native Intel supplied compiler has? > If eliminating the use of __P() in our code means that we dont need to spend > developer-weeks of time every 6 months, then it is damn well worth it. I don't understand this statement. I don't see how time is being saved by having this discussion in the first place. > > For example, taking the TCP/IP stack by itself, with all > > the DOS attack hardening and other hardenening, and using > > it in a system other than FreeBSD. > > I hope you noticed that all that code is nearly pure ANSI. Yes, I had noticed that the syncache code used unprotected prototypes. This is not inconsistent with my first posting in this thread, which noted the current stated FreeBSD policy with regard to new code. > *Bad* example! Your choice of the syncache/syncookie code was a bad example; for the most part, it does not fall into the "hardeneing" category. If you want to discuss the architectural issues with this code, we should start a different thread. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 19:46:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id 39CED37B417 for ; Wed, 30 Jan 2002 19:46:23 -0800 (PST) Received: (qmail 8788 invoked by uid 3130); 31 Jan 2002 03:46:22 -0000 Date: Wed, 30 Jan 2002 22:46:22 -0500 From: Garrett Rooney To: Terry Lambert Cc: Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020131034622.GA63522@electricjellyfish.net> References: <20020131025121.308C13A9A@overcee.wemm.org> <3C58BC92.44F5ED37@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C58BC92.44F5ED37@mindspring.com> User-Agent: Mutt/1.3.25i Sender: owner-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, Jan 30, 2002 at 07:40:02PM -0800, Terry Lambert wrote: > > Nope. Nobody says you have to maintain it. Besides, FreeBSD isn't going > > to run on any system so obscure that it wont have some sort of ansi > > compiler available any time in the forseeable future. > > Oops; three years, not two. Please read section 3(b) of the GPL > at: > > http://www.gnu.org/licenses/gpl.html > distributing source code is not the same as maintaining it. the section you're refering to is: "Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or," this doesn't say anything other than you have to provide the source code. i fail to see how you get 'maintain' from this. -garrett -- garrett rooney Unix was not designed to stop you from rooneg@electricjellyfish.net doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 20: 4:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 67A2837B400 for ; Wed, 30 Jan 2002 20:04:04 -0800 (PST) Received: from pool0224.cvx40-bradley.dialup.earthlink.net ([216.244.42.224] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16W8RC-0006H0-00; Wed, 30 Jan 2002 20:03:20 -0800 Message-ID: <3C58C1D8.D6A71365@mindspring.com> Date: Wed, 30 Jan 2002 20:02:32 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Giorgos Keramidas , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@freebsd.org Subject: Re: __P macro question References: <20020131030329.2E01C3A9A@overcee.wemm.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 Peter Wemm wrote: > > The point is that if I were wanting to use a freely > > available reference implementation of TCP/IP, right > > now I would prefer to use FreeBSDs implementation, so > > long as it remains portable to my platform. > > Well, our network stack is nowhere near K&R compliant, not by a million > miles. So forget that line of the argument. Willful negligence is not a philosophical argument. > > One of the *points* to using Open Source code at all > > is to reduce your maintenance burden and bootstrap > > overhead. > > Ahh you see, that is a problem. The FreeBSD project's purpose is to make a > viable free operating system, not to bend over backwards to make it > convenient for other vendors who want to take our code and run it on a cpu > from 1974 with a compiler from 1973. We the project have no such > obligations. *If* our code is useful, then go for your life. If not, then > too bad. We have no obligation to *support* some arbitary fictitious > vendor who is so damn cheap that they want to save 3 seconds of engineer > time to run unprotoize on components of our source tree. To my mind, the purpose of the project is to produce code, without attaching constraints on how or where that code can be used. The use of that code by as much of the ecological niche in which the code is suited as possible furthers another goal: it ensures interoperability of systems with otherwise dissimilar goals. In other words, it is the next step better than publication of protocol definitions. What is the point of a reference implementation, if it is never used as reference? The distinguishing feature that seperates FreeBSD and Linux is the license, and the uses to which the code can be put are, I think, the primary reason people choose to contribute to FreeBSD, over contributing to Linux. Anything which touches on the fundamental utility of the resulting code, whether it's a license change, or a style change or discontinuation of the use of a portability tool, *should* be considered carefully. > > While it is valid to state that there is other work to > > do, that other work is unavoidable. We are talking > > about increasing the avoidable work here. > > If you add up the number of developer hours that have been wasted over the > last 8 to 10 years on this subject and reapply it to kernel development, > we'd have *finished* SMPng by now. No we wouldn't. There is considerable dissent over the value of SMPng and the approach taken, and those hours would therefore have been applied to other tasks, if they were applied to code, at all. That is the problem with volunteer efforts: you can not schedule or level resources: people volunteer for what they volunteer for, or FreeBSD would have had a new installer by now. Even funding the work was not able to get this accomplished, because the funded work had to transit the gatekeeper(s). As Jordan has been heard to say, "it is like hearding cats". The only thing you can do is attempt to influence the gatekeeper(s), if there are any... as this thread is attempting to do, and is why you and I are participating in it still, I think. All in all, a clearer policy statement would have avoided the question that raised the issue, in any case. In my original posting in this thread, I noted both the currently stated policy which was apparently inadequately communicated (ANSIfication of new code, leaving old code alone), and the reasoning behind the __P() existing. Whether you agree with the validity of the reasons or not does not make them any less the reasons. All the fuss and blather of people reacting to their validity is a side issue, in any case. The only thing of value here is whether or not there will be a policy change on the basis of this discussion, and whether or not such a policy change will be a result of a consensus among the *BSD camps (in which case it should wait until BSDCON for discussion), or whether it will be made by fiat. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 20:24: 8 2002 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 BB1A837B429 for ; Wed, 30 Jan 2002 20:23:06 -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 g0V4M4d68582; Wed, 30 Jan 2002 20:22:04 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Terry Lambert Cc: Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Message from Terry Lambert of "Wed, 30 Jan 2002 19:40:02 PST." <3C58BC92.44F5ED37@mindspring.com> Date: Wed, 30 Jan 2002 20:22:04 -0800 Message-ID: <68578.1012450924@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 Can you guys please remove Dallas from the CC line? I think this debate has long since ceased to have any relevance to him and he's probably just too polite to say anything. :-) > Peter Wemm wrote: > > > 1) You risk becoming the compiler maintainer for 2 > > > years, in order to comply with the license. > > > > Nope. Nobody says you have to maintain it. Besides, FreeBSD isn't going > > to run on any system so obscure that it wont have some sort of ansi > > compiler available any time in the forseeable future. > > Oops; three years, not two. Please read section 3(b) of the GPL > at: > > http://www.gnu.org/licenses/gpl.html > > > > 2) It is another barrier to using BSD code. > > > > So? > > So it is a barrier to contributing to a BSD project as a means > of promoting progress in the art and science, and, in general, > for betterment of the human condition. > > > versus what? GNU code which is also ANSI? > > Versus anything. The GNU code is already irrelevent, in that > it classifies some people as being less deserving than others, > and so it is not in the same category, since it has little or > no utility as a reference implementation for other than > interoperability testing. > > > > > 3) The GCC compiler is sub-par on many architectures. > > > > It tends to work better on older platforms than newer ones. > > How will this get the same P4 instruction pipelining optimization > performance that the native Intel supplied compiler has? > > > If eliminating the use of __P() in our code means that we dont need to spen d > > developer-weeks of time every 6 months, then it is damn well worth it. > > I don't understand this statement. I don't see how time is > being saved by having this discussion in the first place. > > > > > For example, taking the TCP/IP stack by itself, with all > > > the DOS attack hardening and other hardenening, and using > > > it in a system other than FreeBSD. > > > > I hope you noticed that all that code is nearly pure ANSI. > > Yes, I had noticed that the syncache code used unprotected > prototypes. This is not inconsistent with my first posting > in this thread, which noted the current stated FreeBSD policy > with regard to new code. > > > > *Bad* example! > > Your choice of the syncache/syncookie code was a bad example; > for the most part, it does not fall into the "hardeneing" > category. If you want to discuss the architectural issues > with this code, we should start a different thread. > > -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 23: 1:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 6A12637B402 for ; Wed, 30 Jan 2002 23:01:29 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id g0V71Ci75803; Wed, 30 Jan 2002 23:01:12 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200201310701.g0V71Ci75803@beastie.mckusick.com> To: arch@FreeBSD.ORG Subject: Re: __P macro question Cc: Terry Lambert , Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Dallas De Atley , Jordan Hubbard , "Perry E. Metzger" , "Todd C. Miller" , Theo de Raadt In-Reply-To: Your message of "Wed, 30 Jan 2002 20:22:04 PST." <68578.1012450924@winston.freebsd.org> Date: Wed, 30 Jan 2002 23:01:12 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As the initial perpetrator of __P(()) I will be the Nth to say (where N is a distressingly large number) that its usefulness has long gone. Since a big objection has been coordinating with the other BSD's, I took the liberty of asking them (see responses below). They are just as eager to get rid of it, but have been waiting for the other BSD's as well. Time's up. We all agree, __P(()) should be history. Let's all just set about making it so and get on with something important. Kirk McKusick =-=-=-=-= From: "Perry E. Metzger" To: Kirk McKusick Cc: perry@wasabisystems.com Subject: Re: __P(()) Macro Date: 30 Jan 2002 23:41:35 -0500 Kirk McKusick writes: > The FreeBSD mailing list is having their annual debate about removing > the __P(()) macro. While it is generally agreed that its time has come > and gone, one of the big remaining stumbling blocks is to avoid > introducing massive gratuitous code differences with the other BSD > varients. So, I would like to find out if NetBSD has any interest > in going on a systematic purge of __P(()) so that all the groups > could move together at roughly the same time. I think there is widespread interest in doing so. One of our major concerns has been gratuitous code differences vs. other BSDs, but if FreeBSD moved at the same time it might be a much smaller problem. Some scripts should be able to manage the heavy lifting pretty easily and would be simple to share. By the way, our latest style guide says all *new* code is ANSI, but you're generally only supposed to change old code if you're reworking a file for other reasons. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/ =-=-=-=-=-= To: Kirk McKusick cc: Theo de Raadt Subject: Re: __P(()) Macro Date: Wed, 30 Jan 2002 20:33:34 -0700 From: "Todd C. Miller" [ Theo is out of the country and generally w/o net access for another couple of weeks]. In message <200201310328.g0V3Sci74844@beastie.mckusick.com> so spake Kirk McKusick (mckusick): > FreeBSD's current policy is also not to use __P(()) in new code. > The current proposal is to simply remove the __P(()), not to convert > the function headers (which may be a reasonable thing to do, but is > not part of the current plan). Ah, OK then that is not a big deal at all. I did a straw poll among OpenBSD folks active on our icb server and no one objects to this. > I concur that lex and yacc should be able to generate K&R code, but > probably not using __P(()). Rather grouping all the function > prototypes into one place and putting some sort of ifdef around them. Yes, that sounds prefectly reasonable. - todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 23:15:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 460C137B404 for ; Wed, 30 Jan 2002 23:15:26 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 4026C2175; Thu, 31 Jan 2002 08:15:24 +0100 (CET) Date: Thu, 31 Jan 2002 08:15:23 +0100 From: Jeroen Ruigrok/asmodai To: Terry Lambert Cc: Peter Wemm , Giorgos Keramidas , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@freebsd.org Subject: Re: __P macro question Message-ID: <20020131071523.GP22384@daemon.ninth-circle.org> References: <20020131030329.2E01C3A9A@overcee.wemm.org> <3C58C1D8.D6A71365@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C58C1D8.D6A71365@mindspring.com> User-Agent: Mutt/1.3.24i 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 [20020131 05:15], Terry Lambert (tlambert2@mindspring.com) wrote: >Peter Wemm wrote: >> > The point is that if I were wanting to use a freely >> > available reference implementation of TCP/IP, right >> > now I would prefer to use FreeBSDs implementation, so >> > long as it remains portable to my platform. >> >> Well, our network stack is nowhere near K&R compliant, not by a million >> miles. So forget that line of the argument. > >Willful negligence is not a philosophical argument. Willful laziness is not a developer forte. One's ease of porting is another man's pain in removing things from the sources. If you want portability, go with NetBSD, FreeBSD already said in the past that it had no desire to be ported to Apollo's to replace Domain/OS or any other old architectures. You want software from FreeBSD and use it in your own environment, well tough luck, chances are you need to get off your butt and do what you were hired for in the first place. We are not talking about any philosophical pies in the sky here, this is code, pure and simple. Yes, we remove K&R's __P() macro support, because of: - argument - argument - argument - argument No, we leave K&R's __P() macro support be, because of: - argument - argument - argument - argument Where is the philosophical discussion in that? -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ In shallow waters, shrimps make fools of dragons. - Chinese Proverb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 23:29:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 12CE437B402; Wed, 30 Jan 2002 23:29:35 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id C5B9D216F; Thu, 31 Jan 2002 08:29:33 +0100 (CET) Date: Thu, 31 Jan 2002 08:29:33 +0100 From: Jeroen Ruigrok/asmodai To: Kirk McKusick Cc: arch@FreeBSD.ORG, Peter Wemm , Poul-Henning Kamp , Dallas De Atley , Jordan Hubbard , "Perry E. Metzger" , "Todd C. Miller" , Theo de Raadt Subject: Re: __P macro question Message-ID: <20020131072933.GQ22384@daemon.ninth-circle.org> References: <68578.1012450924@winston.freebsd.org> <200201310701.g0V71Ci75803@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201310701.g0V71Ci75803@beastie.mckusick.com> User-Agent: Mutt/1.3.24i 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 [20020131 08:15], Kirk McKusick (mckusick@mckusick.com) wrote: >As the initial perpetrator of __P(()) I will be the Nth to say >(where N is a distressingly large number) that its usefulness >has long gone. Since a big objection has been coordinating with >the other BSD's, I took the liberty of asking them (see responses >below). They are just as eager to get rid of it, but have been >waiting for the other BSD's as well. Time's up. We all agree, >__P(()) should be history. Let's all just set about making it >so and get on with something important. Ok, so allow me to drag this line a bit further, and this will interest Dallas probably as well: Can we make a combined effort, OpenBSD, NetBSD, FreeBSD and Darwin/Mac OS X to target getting rid of this in our respective CURRENT/development trees? Which items can we identify to tackle in this effort? - Get rid of __P() macros in source files - Use proper ANSI prototypes, this flows from the point above what else? Are there any choking points? As far as I can see we all have compilers which should not give any problems with this. What would be the timeframe in which we want to accomplish this? -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ We've laid together in the sun before the mind-rape has begun... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 23:34:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 5CA2737B404 for ; Wed, 30 Jan 2002 23:34:31 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 5B832216F; Thu, 31 Jan 2002 08:34:30 +0100 (CET) Date: Thu, 31 Jan 2002 08:34:30 +0100 From: Jeroen Ruigrok/asmodai To: Bakul Shah Cc: arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020131073430.GR22384@daemon.ninth-circle.org> References: <66502.1012413380@winston.freebsd.org> <200201301931.OAA26085@glatton.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201301931.OAA26085@glatton.cnchost.com> User-Agent: Mutt/1.3.24i 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 [20020130 20:45], Bakul Shah (bakul@bitblocks.com) wrote: >Similarly, if Terry were to make the changes to the FreeBSD >kernel to compile it with TenDRA (and make it work) at least >I would be very grateful to him -- I do think relying so much >on GCC is a bad idea but I am realistic (and lazy) enough to >not want to fix that on my own. As someone who has been hacking TenDRA for a while now and trying to get it up-to-date a bit, I can tell you FreeBSD is written in a C dialect called GCC C. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ Any road leads to the end of the world... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 30 23:56:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from badboy.mail.pas.earthlink.net (badboy.mail.pas.earthlink.net [207.217.120.20]) by hub.freebsd.org (Postfix) with ESMTP id 97D3637B400 for ; Wed, 30 Jan 2002 23:56:15 -0800 (PST) Received: from harrier.mail.pas.earthlink.net ([207.217.120.12] helo=harrier.prod.itd.earthlink.net) by badboy.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16WC0m-0007fB-00 for arch@freebsd.org; Wed, 30 Jan 2002 23:52:00 -0800 Received: from pool0237.cvx21-bradley.dialup.earthlink.net ([209.179.192.237] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WC0d-0004oF-00; Wed, 30 Jan 2002 23:51:51 -0800 Message-ID: <3C58F78E.3F66EA8E@mindspring.com> Date: Wed, 30 Jan 2002 23:51:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/asmodai Cc: Kirk McKusick , arch@FreeBSD.ORG, Peter Wemm , Poul-Henning Kamp , Dallas De Atley , Jordan Hubbard , "Perry E. Metzger" , "Todd C. Miller" , Theo de Raadt Subject: Re: __P macro question References: <68578.1012450924@winston.freebsd.org> <200201310701.g0V71Ci75803@beastie.mckusick.com> <20020131072933.GQ22384@daemon.ninth-circle.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeroen Ruigrok/asmodai wrote: > Which items can we identify to tackle in this effort? > > - Get rid of __P() macros in source files > - Use proper ANSI prototypes, this flows from the point above > > what else? Other candidates are other macros in cdefs.h; because of the __attribute stuff, I would be loathe to get rid of it entirely, since it encapsulates some GCC dependence/independence, but the const/void/volatile definitions are a possibility. There are also the varradic function declarations, which are not all ANSI-C style, yet, use of __STRING and __CONCAT, etc.. My recommendation would be to do __P() first, now that there is a cross-BSD consensus, and leave other changes for other discussions. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 0: 3:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id F3C7137B400 for ; Thu, 31 Jan 2002 00:03:44 -0800 (PST) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16WCBe-00030k-00; Thu, 31 Jan 2002 01:03:14 -0700 Message-ID: <3C58FAAD.78550974@softweyr.com> Date: Thu, 31 Jan 2002 01:05:01 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: "M. Warner Losh" , deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question References: <63609.1012386890@axl.seasidesoftware.co.za> <3C5895A5.D65A3ADB@mindspring.com> <20020130.183139.84750367.imp@village.org> <3C58A9C2.6890CB19@mindspring.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 Terry Lambert wrote: > > ... that tty > manipulation can be abstracted down to 6 system interfaces, > and made relatively very portable; I wrote code that ran > on approximately 140 vendor implementations of UNIX, with > only 3 variant files. ] But it was code of very limited "touch" to the system. Sure, it did serial I/O, which is rarely much fun on UNIX, let alone to do portably on UNIX, but that was also the most ambitious it got. Don't try to extrapolate that example too far, Terry. {Yes, I worked on that code too, and ported it to several systems that did not exist when Terry wrote it. HP/UX 10 threw some interesting curves at it, as did AIX 4.1} -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 0: 9: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id A9CA137B416 for ; Thu, 31 Jan 2002 00:09:04 -0800 (PST) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16WCH2-000319-00; Thu, 31 Jan 2002 01:08:48 -0700 Message-ID: <3C58FBEC.746257BB@softweyr.com> Date: Thu, 31 Jan 2002 01:10:20 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Jeroen Ruigrok/asmodai , Kirk McKusick , arch@FreeBSD.ORG, Peter Wemm , Poul-Henning Kamp , Dallas De Atley , Jordan Hubbard , "Perry E. Metzger" , "Todd C. Miller" , Theo de Raadt Subject: Re: __P macro question References: <68578.1012450924@winston.freebsd.org> <200201310701.g0V71Ci75803@beastie.mckusick.com> <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.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 Terry Lambert wrote: > > Jeroen Ruigrok/asmodai wrote: > > Which items can we identify to tackle in this effort? > > > > - Get rid of __P() macros in source files > > - Use proper ANSI prototypes, this flows from the point above Sort of. If you mean "edit the __P() macros into prototypes with the same footprint", that's a good starting point. A logical next step would be to check each of our newly prototyped functions against Posix/SUS and become more standards compliant. > > what else? > > Other candidates are other macros in cdefs.h; because of the > __attribute stuff, I would be loathe to get rid of it entirely, > since it encapsulates some GCC dependence/independence, but the > const/void/volatile definitions are a possibility. > > There are also the varradic function declarations, which are > not all ANSI-C style, yet, use of __STRING and __CONCAT, etc.. > > My recommendation would be to do __P() first, now that there > is a cross-BSD consensus, and leave other changes for other > discussions. Always a sensible choice, just to keep the CVS commits atomic if no other reason. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 1:13:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by hub.freebsd.org (Postfix) with ESMTP id 68EFB37B41B for ; Thu, 31 Jan 2002 01:13:03 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g0V9CwQ14056 for ; Thu, 31 Jan 2002 10:12:58 +0100 (CET) Received: from falcon.midgard.homeip.net (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id KAA00628 for ; Thu, 31 Jan 2002 10:12:57 +0100 (CET) Received: (qmail 64673 invoked by uid 1001); 31 Jan 2002 09:12:55 -0000 Date: Thu, 31 Jan 2002 10:12:54 +0100 From: Erik Trulsson To: Terry Lambert Cc: Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020131091254.GA61188@student.uu.se> Mail-Followup-To: Terry Lambert , Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Jordan Hubbard , Dallas De Atley , arch@FreeBSD.ORG References: <20020131025121.308C13A9A@overcee.wemm.org> <3C58BC92.44F5ED37@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C58BC92.44F5ED37@mindspring.com> User-Agent: Mutt/1.3.25i Sender: owner-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, Jan 30, 2002 at 07:40:02PM -0800, Terry Lambert wrote: > Peter Wemm wrote: > > > 1) You risk becoming the compiler maintainer for 2 > > > years, in order to comply with the license. > > > > Nope. Nobody says you have to maintain it. Besides, FreeBSD isn't going > > to run on any system so obscure that it wont have some sort of ansi > > compiler available any time in the forseeable future. > > Oops; three years, not two. Please read section 3(b) of the GPL > at: > > http://www.gnu.org/licenses/gpl.html You seem to have misunderstood the GPL. Section 3 says that if you give somebody a GPL'd binary you must also do *one* of a) b) and c) where b) is an offer valid for at least 3 years to supply the source on demand. But you can just do a), which means supply the source together with the binary. Then you have no further obligations. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 2: 9:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from deathrow.mail.pas.earthlink.net (deathrow.mail.pas.earthlink.net [207.217.120.19]) by hub.freebsd.org (Postfix) with ESMTP id 7B5E637B417 for ; Thu, 31 Jan 2002 02:09:38 -0800 (PST) Received: from harrier.mail.pas.earthlink.net ([207.217.120.12] helo=harrier.prod.itd.earthlink.net) by deathrow.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16WBvC-0005Bn-00 for arch@freebsd.org; Wed, 30 Jan 2002 23:46:14 -0800 Received: from pool0237.cvx21-bradley.dialup.earthlink.net ([209.179.192.237] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WBuk-0001ck-00; Wed, 30 Jan 2002 23:45:47 -0800 Message-ID: <3C58F620.8A1EF5B7@mindspring.com> Date: Wed, 30 Jan 2002 23:45:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kirk McKusick Cc: arch@FreeBSD.ORG, Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Dallas De Atley , Jordan Hubbard , "Perry E. Metzger" , "Todd C. Miller" , Theo de Raadt Subject: Re: __P macro question References: <200201310701.g0V71Ci75803@beastie.mckusick.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kirk McKusick wrote: > As the initial perpetrator of __P(()) I will be the Nth to say > (where N is a distressingly large number) that its usefulness > has long gone. Since a big objection has been coordinating with > the other BSD's, I took the liberty of asking them (see responses > below). They are just as eager to get rid of it, but have been > waiting for the other BSD's as well. Time's up. We all agree, > __P(()) should be history. Let's all just set about making it > so and get on with something important. Thank you, Kirk. I withdraw my objections to the process, since it is more important to maintain source compatability and the ability to move diff's between the various BSDs, than all other considerations, valid though they may be, combined. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 2:58:53 2002 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 92C7437B419 for ; Thu, 31 Jan 2002 02:58:41 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16WEyI-000Kd3-00 for arch@FreeBSD.org; Thu, 31 Jan 2002 13:01:38 +0200 From: Sheldon Hearn To: arch@FreeBSD.org Subject: Adding support for a global src tree serial number Date: Thu, 31 Jan 2002 13:01:38 +0200 Message-ID: <79300.1012474898@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 Hi folks, I'd like to propose the addition of a global src tree serial number that uniquely identifies an imaginary snapshot of the src tree. Essentially, the serial number lives in a file, the name of which is not important until I have buy-in on the concept. Let's call it src/SERIAL for now. Every time a delta is applied to a branch, the serial number in src/SERIAL is automatically incremented through a "stealth commit" on that branch. This ensures that, if the src tree is checked out in its entirety and left unmodified, this serial number identifies the state of the entire tree. In addition, the serial number will be included in the commonly requested output of 'uname -a' through modifications ot newvers.sh. This is of no value to developers who update, build and install portions of the tree, instead of the entire tree. However, I think it is of great value to folks tracking STABLE, for the following reasons: 1) Folks reporting build failures can be asked to quote the serial number of the src tree they're building. 2) Folks reporting post-upgrade problems can show the serial number of the src used for the upgrade, since it's available in the kernel version string reported by 'uname -a'. 3) The src/UPDATING file can reference the serial number, e.g. This problem was introduced in serial number 11809 and was corrected in serial number 11832. Obviously, src/UPDATING would need to explain how to find the serial number in src/SERIAL. If folks approve of this idea, Joseph Karthauser has already offered to do the necessary work in our CVS commit scripts. This idea flows out of PR conf/6346, and is something I've thought about on and off since Mark Murray and I argued about it over beer about 2 years ago. 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 Jan 31 3:28:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from cisco.com (europe.cisco.com [144.254.52.73]) by hub.freebsd.org (Postfix) with ESMTP id E434237B402 for ; Thu, 31 Jan 2002 03:28:18 -0800 (PST) Received: from cobweb.example.org (dhcp-nic-val-26-117.cisco.com [64.103.26.117]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id MAA10922 for ; Thu, 31 Jan 2002 12:28:09 +0100 (MET) Received: (qmail 28462 invoked by uid 1000); 31 Jan 2002 11:28:50 -0000 Date: Thu, 31 Jan 2002 12:28:50 +0100 From: Marco Molteni To: arch@FreeBSD.org Cc: Sheldon Hearn Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131112850.GB28361@cobweb.example.org> References: <79300.1012474898@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za> User-Agent: Mutt/1.3.25i Sender: owner-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 Sheldon, the only drawback I see to your approach is that the serial number you are proposing is dateless, so folks will probably ask for a date too: > This problem was introduced in serial number 11809 and was > corrected in serial number 11832. My suggestion is to use a serial number bound to the date the serial number was generated, something like 20020223123435XXXX yyyymmddhhmmss with XXXXX set to the precision you consider appropriate, and the date being GMT. Or maybe something like 20020223-XXXX yyyymmdd where XXXX is the number of changes made in that day up to this change. One difference is that with your proposal two successive serial numbers have a difference of 1, for example 11833 - 11832 = 1, while with mine you loose this. My 0.02 euros marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 4: 4:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 74D1837B404 for ; Thu, 31 Jan 2002 04:04:49 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0VC43n71620; Thu, 31 Jan 2002 14:04:03 +0200 (EET) (envelope-from ru) Date: Thu, 31 Jan 2002 14:04:03 +0200 From: Ruslan Ermilov To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131140403.A69232@sunbay.com> References: <79300.1012474898@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za> 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 Thu, Jan 31, 2002 at 01:01:38PM +0200, Sheldon Hearn wrote: > > Hi folks, > > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. > > Essentially, the serial number lives in a file, the name of which is > not important until I have buy-in on the concept. Let's call it > src/SERIAL for now. > > Every time a delta is applied to a branch, the serial number in > src/SERIAL is automatically incremented through a "stealth commit" on > that branch. This ensures that, if the src tree is checked out in its > entirety and left unmodified, this serial number identifies the state of > the entire tree. > It's contents should be a Message-Id of the last commit mail for a particular branch (X-FreeBSD-CVS-Branch). This scheme won't work because the state of the tree can be modified by CVS meisters performing direct operations on a repository. See how stealthy the latest GCC import gone. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 4:16:25 2002 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 CB4D737B400 for ; Thu, 31 Jan 2002 04:16:10 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16WGB6-000Khw-00; Thu, 31 Jan 2002 14:18:56 +0200 From: Sheldon Hearn To: Marco Molteni Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number In-reply-to: Your message of "Thu, 31 Jan 2002 12:28:50 +0100." <20020131112850.GB28361@cobweb.example.org> Date: Thu, 31 Jan 2002 14:18:56 +0200 Message-ID: <79603.1012479536@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, 31 Jan 2002 12:28:50 +0100, Marco Molteni wrote: > the only drawback I see to your approach is that the serial number you are > proposing is dateless, so folks will probably ask for a date too: > > > This problem was introduced in serial number 11809 and was > > corrected in serial number 11832. I can see why support folks would want a date, however it's a trivial thing to determine from the CVS logs for the src/SERIAL file. [1] That said, I can't think of any reason _not_ to prepend a date string to the serial number. You said this: > One difference is that with your proposal two successive serial > numbers have a difference of 1, for example 11833 - 11832 = 1, while > with mine you loose this. But I can't see any value in knowing the number of commits made to the entire tree between two snapshots. Another advantage of your idea is that it allows for a fixed-width serial number until a) The year 10000AD. b) The number of commits (not deltas!) per day reaches an unexpectedly high number. For example, we could say that the serial number should be constructed as follows: YYYYMMDDXXXXXXX 200201310000001 This example shows the first commit of the day for 31 January 2001 (freefall time). Here, we use 4 digits to represent the year, 2 digits to represent the month, 2 digits to represent the day and 7 digits to represent the commit. This assumes that we would never see more than 999,999 commits in a single day. I'm not sure this will happen before the year 10000AD. ;-) Ciao, Sheldon. [1] And anyway, do we really want to clutter the serial file with CVS revision Id, which may cause confusion? Certainly, we won't be allowing manual commits to this file! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 4:18: 3 2002 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 0516037B404; Thu, 31 Jan 2002 04:18:00 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16WGD3-000KiT-00; Thu, 31 Jan 2002 14:20:57 +0200 From: Sheldon Hearn To: Ruslan Ermilov Cc: arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-reply-to: Your message of "Thu, 31 Jan 2002 14:04:03 +0200." <20020131140403.A69232@sunbay.com> Date: Thu, 31 Jan 2002 14:20:57 +0200 Message-ID: <79636.1012479657@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, 31 Jan 2002 14:04:03 +0200, Ruslan Ermilov wrote: > This scheme won't work because the state of the tree can be modified > by CVS meisters performing direct operations on a repository. See > how stealthy the latest GCC import gone. I don't think there are so many CVS meisters, or so much src repo surgery, that having them bump the serial number manually in these cases is a problem. 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 Jan 31 4:40:21 2002 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 B16EF37B404 for ; Thu, 31 Jan 2002 04:40:17 -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 XAA13362; Thu, 31 Jan 2002 23:37:28 +1100 Date: Thu, 31 Jan 2002 23:38:58 +1100 (EST) From: Bruce Evans X-X-Sender: To: "M. Warner Losh" Cc: , , Subject: Re: __P macro question In-Reply-To: <20020130.145424.00452635.imp@village.org> Message-ID: <20020131231008.P4085-100000@gamplex.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 Wed, 30 Jan 2002, M. Warner Losh wrote: > I'm going through bin right now removing __P() and making the > functions have new-style rather than old-style decls. It is a nice > little mindless thing to do when to relax and unwind. I plan on > committing this this weekend (see below). I've seen nothing so far to > tell me not to do it: Don't do it all. Some people prefer old-style decls, and unlike __P(()), they don't involve any preprocessor hackery; they are part of ISO C. Kirks' mail to OpenBSD explicitly said that changing the decls is not being considered now: % > In message <200201310328.g0V3Sci74844@beastie.mckusick.com> % so spake Kirk McKusick (mckusick): % > FreeBSD's current policy is also not to use __P(()) in new code. % > The current proposal is to simply remove the __P(()), not to convert % > the function headers (which may be a reasonable thing to do, but is % > not part of the current plan). When removing __P(()), don't do it like login/login.c rev.1.80: - mix the removal with nontrivial rewriting of the code to make it harder for auditors to see the critical changes. Change all the function headers too, but don't de-verbosify the code by removing the prototypes made redundant by this. - be sure to unsort the prototypes and add excessive indentation to them. Using a low quality script to regenerate all the prototypes is a good way to do this. ;-) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 4:44:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7D10C37B417 for ; Thu, 31 Jan 2002 04:44:06 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0VChjw77303; Thu, 31 Jan 2002 14:43:45 +0200 (EET) (envelope-from ru) Date: Thu, 31 Jan 2002 14:43:45 +0200 From: Ruslan Ermilov To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131144345.A73522@sunbay.com> References: <20020131140403.A69232@sunbay.com> <79636.1012479657@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79636.1012479657@axl.seasidesoftware.co.za> 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 Thu, Jan 31, 2002 at 02:20:57PM +0200, Sheldon Hearn wrote: > > > On Thu, 31 Jan 2002 14:04:03 +0200, Ruslan Ermilov wrote: > > > This scheme won't work because the state of the tree can be modified > > by CVS meisters performing direct operations on a repository. See > > how stealthy the latest GCC import gone. > > I don't think there are so many CVS meisters, or so much src repo > surgery, that having them bump the serial number manually in these cases > is a problem. > "commit" is atomic operation, while direct manipulation of repository isn't. To make it atomic, CVS meisters would have to lock src/, make the necessary surgery, bump serial number, then unlock it. > 1) Folks reporting build failures can be asked to quote the serial > number of the src tree they're building. > Mirroring of CVS repositories with CVSup could be a problem here. We'd need to somehow guarantee that src/SERIAL is consistent with the rest of the checked out sources. What if the mirror site you are "cvs updating" from is experiencing a CVSup latency, and some checked out sources are still behind SERIAL? This is not an unlikely thing to see. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 4:57: 2 2002 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 D4F7837B402; Thu, 31 Jan 2002 04:56:56 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16WGoi-000Kms-00; Thu, 31 Jan 2002 14:59:52 +0200 From: Sheldon Hearn To: Ruslan Ermilov Cc: arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-reply-to: Your message of "Thu, 31 Jan 2002 14:43:45 +0200." <20020131144345.A73522@sunbay.com> Date: Thu, 31 Jan 2002 14:59:52 +0200 Message-ID: <79909.1012481992@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, 31 Jan 2002 14:43:45 +0200, Ruslan Ermilov wrote: > Mirroring of CVS repositories with CVSup could be a problem here. > We'd need to somehow guarantee that src/SERIAL is consistent with > the rest of the checked out sources. What if the mirror site you > are "cvs updating" from is experiencing a CVSup latency, and some > checked out sources are still behind SERIAL? This is not an > unlikely thing to see. Well this is where my argument falls completely to the ground. [1] :-) I didn't realize that cvsup mirrors might offer me a src/bin that's newer than the src/sbin that it offers me (for example). If that's the case, then this is a bit of a lost cause. Ciao, Sheldon. [1] With apologies to Monty Python. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 5:17:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id C69A437B405 for ; Thu, 31 Jan 2002 05:17:17 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 40548D; Thu, 31 Jan 2002 07:17:17 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0VDHF487914; Thu, 31 Jan 2002 07:17:15 -0600 (CST) (envelope-from nectar) Date: Thu, 31 Jan 2002 07:17:15 -0600 From: "Jacques A. Vidrine" To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131131714.GA87780@madman.nectar.cc> References: <79300.1012474898@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jan 31, 2002 at 01:01:38PM +0200, Sheldon Hearn wrote: > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. This is attractive to me, since we already do something like this for the `security' branches (RELENG_4_3 et al). We manually bump $BRANCH in newvers.sh. I imagine it would also be attractive to people on freebsd-binup. Other folks have already pointed out the problems with the scheme, but I want to make a couple of other random comments: = I would like to be able to change this number in a running system. i.e. if patch X is applied to FOO.BAR-RELEASE, I want the system to immediately reflect that it is now FOO.BAR'-RELEASE. = The serial number would need to be different for different branches, and unambiguous. Or all references to the serial number must also include the branch, e.g. 4.5-RELEASE build 9230. = It would be almost as useful if the serial number were simply bumped once a day, every day. = The serial number could be the MD5 of the source tree from which the system was compiled: tar -C /usr/src --exclude CVS -cf - . | md5 I'm currently running 4.5-RELEASE build 10c5be07ecd40c66fc126dd57afd934c. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se OK, you caught me. The last bullet was a joke. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 5:20:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id DE28237B400 for ; Thu, 31 Jan 2002 05:20:43 -0800 (PST) Received: from pool0005.cvx22-bradley.dialup.earthlink.net ([209.179.198.5] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WH8r-000694-00; Thu, 31 Jan 2002 05:20:41 -0800 Message-ID: <3C5944A4.4927F812@mindspring.com> Date: Thu, 31 Jan 2002 05:20:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> 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 Sheldon Hearn wrote: > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. [ ... ] I see several issues; you may already have ways to address them. If I have serial number X, and two commits are started A,B, and the commits complete as either A,B or B,A, is the serial number X+1, X+2 or some other number? The easiest way to handle this would probably be to use a datestamp, in seconds; this would also allow checkout of a specific snapshot. If higher granularity were required, you could add a seperately incrementing value as a nonce. What is the interaction with the serial number and CVSup or explicit checkouts? Is the serial number updates at the start of a checkin, or at the end? Is it possible for the serial number to not match the code atomically? Is the increment on a per file, or a per checking basis? (I could perhaps see per file working better, since there are per file writer locks to prevent simultaneous commits). I don't really see how you could make atomicity guarantees that would keep this serial number from getting off-by-1 in one direction or the other, or off-by-N, in the case of a CVSup in the middle of a large commit (since repository replication is also non-atomic, at present). I definitely agree that it would be useful to be able to have a "magic number" that could get everyone on the same page with regard to a problem. For the "uname -a" idea, you would be better served by using a structure field. There is already version information (such as build date) in the "uname -a" that has to be retrieved by sysctl and string operations performed on it to provide minimal useful information. It would be a shame to compound that by adding more information to an unstructured field. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 5:29:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 6DEF737B405; Thu, 31 Jan 2002 05:29:36 -0800 (PST) Received: from pool0005.cvx22-bradley.dialup.earthlink.net ([209.179.198.5] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WHHR-0004TP-00; Thu, 31 Jan 2002 05:29:34 -0800 Message-ID: <3C5946B8.BAA49BD@mindspring.com> Date: Thu, 31 Jan 2002 05:29:28 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Ruslan Ermilov , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number References: <79636.1012479657@axl.seasidesoftware.co.za> 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 Sheldon Hearn wrote: > On Thu, 31 Jan 2002 14:04:03 +0200, Ruslan Ermilov wrote: > > This scheme won't work because the state of the tree can be modified > > by CVS meisters performing direct operations on a repository. See > > how stealthy the latest GCC import gone. > > I don't think there are so many CVS meisters, or so much src repo > surgery, that having them bump the serial number manually in these cases > is a problem. Another approach might be if you used a mod to CVS to cause it to remember the most recent date of any file it checked out in a batch checkout, and scripted the extraction of that date into a file. Then if you did a local checkout, you would get the date in the file of the last modified file that was checked out, and another checkout later of that date would result in the same sources. There's still a simultaneity problem with checkins that all happen at the "same" time (the the granularity of the date, which is in seconds), but I think this meets your requirements. The only missing puzzle piece is that you would need to cause the use of the scripted checkout by default. This could be done in the Makefile "make cvsworld" target, or something similar. If this wouldn't work, then the alternative is a "cvs stat" scan of the source tree in question, to get the date (e.g. a "make version" target), but you'd still need to hack the CVS program so that it knew the highest delta, or did two scans, so that it knew if any files were modified between the lowest time and the highest to know if any files were out of date (e.g. like the output of a "cvs update -n -D" over the tree, using the highest date from a "cvs stat" over the tree). This could be done after a problem (obviously, it doesn't satisfy the "uname -a" goal, either), which is when people would care about this, except for release snapshots, where we might care about it to reference a particular snapshot. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 5:32:27 2002 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 2A7A837B400 for ; Thu, 31 Jan 2002 05:32:13 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16WHMk-000KyT-00; Thu, 31 Jan 2002 15:35:02 +0200 From: Sheldon Hearn To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number In-reply-to: Your message of "Thu, 31 Jan 2002 05:20:36 PST." <3C5944A4.4927F812@mindspring.com> Date: Thu, 31 Jan 2002 15:35:02 +0200 Message-ID: <80628.1012484102@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, 31 Jan 2002 05:20:36 PST, Terry Lambert wrote: > If I have serial number X, and two commits are started > A,B, and the commits complete as either A,B or B,A, is the > serial number X+1, X+2 or some other number? Always X+2, since two commits have followed since the previous serial number X. > What is the interaction with the serial number and CVSup > or explicit checkouts? Poor, according to Ruslan. This seriously undermines the value of this serial number. > Is the serial number updates at the start of a checkin, > or at the end? At the end. > Is it possible for the serial number to not match the code > atomically? Not in the master repository, but (again, according to Ruslan) this is possible with cvsup mirrors. > Is the increment on a per file, or a per checking basis? > (I could perhaps see per file working better, since there > are per file writer locks to prevent simultaneous commits). Per checkin. > I don't really see how you could make atomicity guarantees > that would keep this serial number from getting off-by-1 in > one direction or the other, or off-by-N, in the case of a > CVSup in the middle of a large commit (since repository > replication is also non-atomic, at present). Yeah, I didn't realize that CVSup isn't at all interested in the checkin process. 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 Jan 31 5:34:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 5A93037B400 for ; Thu, 31 Jan 2002 05:34:31 -0800 (PST) Received: from pool0005.cvx22-bradley.dialup.earthlink.net ([209.179.198.5] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WHM9-00003M-00; Thu, 31 Jan 2002 05:34:26 -0800 Message-ID: <3C5947DC.DB3AD4B2@mindspring.com> Date: Thu, 31 Jan 2002 05:34:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" Cc: Sheldon Hearn , arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> 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 "Jacques A. Vidrine" wrote: > = The serial number could be the MD5 of the source tree from which the > system was compiled: > tar -C /usr/src --exclude CVS -cf - . | md5 > I'm currently running 4.5-RELEASE build 10c5be07ecd40c66fc126dd57afd934c. Uh... are you sure a cryptographic hash of the source you have is going to give enough information for a kernel hacker to recreate the binaries that are causing the problem that resulted in the bug report? I guess I could just check out by second since the start of the source tree, until the hashes matched? 8-) 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 6: 2:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.tninet.se (sheridan.tninet.se [195.100.94.102]) by hub.freebsd.org (Postfix) with ESMTP id 4616A37B404 for ; Thu, 31 Jan 2002 06:02:35 -0800 (PST) Received: from kairos.algonet.se (kairos.algonet.se [194.213.75.171]) by sheridan.tninet.se (BMR ErlangTM/OTP 3.0) with ESMTP id 851272.485748.1012.0s5448140sheridan for ; Thu, 31 Jan 2002 15:02:28 +0100 Received: (qmail 12793 invoked by uid 2493); 31 Jan 2002 14:02:26 -0000 Date: 31 Jan 2002 14:02:26 -0000 Message-ID: <20020131140226.12792.qmail@kairos.algonet.se> From: Mats Lofkvist To: tlambert2@mindspring.com Cc: n@nectar.cc, sheldonh@starjuice.net, arch@FreeBSD.org In-reply-to: <3C5947DC.DB3AD4B2@mindspring.com> (message from Terry Lambert on Thu, 31 Jan 2002 05:34:20 -0800) Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> <3C5947DC.DB3AD4B2@mindspring.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 Terry Lambert wrote: > "Jacques A. Vidrine" wrote: >> = The serial number could be the MD5 of the source tree from which the >> system was compiled: >> tar -C /usr/src --exclude CVS -cf - . | md5 >> I'm currently running 4.5-RELEASE build 10c5be07ecd40c66fc126dd57afd934c. > Uh... are you sure a cryptographic hash of the source > you have is going to give enough information for a > kernel hacker to recreate the binaries that are causing > the problem that resulted in the bug report? > > I guess I could just check out by second since the start > of the source tree, until the hashes matched? > > 8-) 8-) 8-). > > -- Terry Maybe this wouldn't be as bad if the MD5 was done e.g. on a sorted list of file name - version number pairs? It would then be possible to create a tool that automatically tests all combinations given a list of all files and versions that existed in a given time interval. The fact that this explodes exponentially with number-of-files ^ average-number-of-versions probably makes it impractical for use with longer time intervals though :-) But, if you knew the exact order of changes, you could start with a list of all files with versions at the start time and then check the MD5 for all changes until the end time by replacing the version of each changed file. This is only number-of-files * number-of-changes. A combination of these two techniques could be used to get the speed from the later but still allowing for changes 'close enough' in time to be applied in random order. _ Mats Lofkvist mal@algonet.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 6:27: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id E289637B404 for ; Thu, 31 Jan 2002 06:26:55 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.11.6/8.11.3) id g0VDD6M08702; Thu, 31 Jan 2002 08:13:06 -0500 (EST) (envelope-from dufault) Date: Thu, 31 Jan 2002 08:13:06 -0500 From: Peter Dufault To: "M. Warner Losh" Cc: drosih@rpi.edu, deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020131081306.A8666@hda.hda.com> References: <20020130.145424.00452635.imp@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: <20020130.145424.00452635.imp@village.org>; from imp@village.org on Wed, Jan 30, 2002 at 02:54:24PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 30, 2002 at 02:54:24PM -0700, M. Warner Losh wrote: > I've yet to see a compelling argument against me doing this. You have > until Friday to make a compelling case. The time has come for this > change. bin gets committed this weekend. I'll post diffs on Friday > and commit Sunday/Monday. So far, no one has replied to my other mail > that threatened to do this, so I'm taking that as agreement. > > Comments? I think an initial commit pass done strictly by a script, even if it has some drawbacks, could help reduce diffs against the other BSDs as they could use the same script. Peter PS: I'm sure I do more embedded work than most others, and actively support "64K split I&D" microcontrollers and DSP architectures. I share "Terry's problem", I don't share "Terry's solution". This process is long overdue, anyone wishing to know more details of my opinion should do a google search for discussions we had six years ago. -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 7:38:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.68.253]) by hub.freebsd.org (Postfix) with ESMTP id 1440B37B41C for ; Thu, 31 Jan 2002 07:38:17 -0800 (PST) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id AAA31332 for ; Fri, 1 Feb 2002 00:36:36 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200201311536.AAA31332@shidahara1.planet.sci.kobe-u.ac.jp> To: arch@freebsd.org Subject: Re: How about removing #ifdef DEV_ISA from autoconf.c In-reply-to: Your message of "Thu, 31 Jan 2002 06:50:09 +1100." <20020131064141.X55787-100000@gamplex.bde.org> Date: Fri, 01 Feb 2002 00:36:36 +0900 From: Takanori Watanabe Sender: owner-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 <20020131064141.X55787-100000@gamplex.bde.org>, Bruce Evans $B$5$s$$$o(B $B$/(B: >On Thu, 31 Jan 2002, Takanori Watanabe wrote: > >> Hi, I have a patch to be reviewed. >> This removes #ifdef DEV_ISA from sys/i386/autoconf.c and >> allows to intercept before and after isa_prove_children() executed. >> This will enable us statisize isa_probe_children, though what I want to do >> is to execute isa_probe_children-like routine in acpi module >> after isa_probe_children is exeuted. >> >> This patch contains patch to i386/i386/autoconf.h and isa/isa_common.c and >> new sys/autoconf.h file. >> >> How do you think about it? > >The complications to get interrupts enabled at the correct time aren't >needed in -current since spl0() has no effect. Interrupts are enabled >at incorrect times earlier :-). I guess masking in the ICU prevents >serious problems. Hmm, I know spl0() is no effect any more, some stubs will need to disable/enable during autoconfiguration. Or should it be in configure_final()? BTW, I update the patch that can be apply for other archtectures. (alpha,ia64,i386) http://people.freebsd.org/~takawata/isadiff http://people.freebsd.org/~takawata/autoconf.h Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 7:45:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 2D75837B400 for ; Thu, 31 Jan 2002 07:45:21 -0800 (PST) Received: by gw.nectar.cc (Postfix, from userid 1001) id 9A103D; Thu, 31 Jan 2002 09:45:20 -0600 (CST) Date: Thu, 31 Jan 2002 09:45:20 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: Sheldon Hearn , arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131094520.C50489@hellblazer.nectar.cc> References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> <3C5947DC.DB3AD4B2@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C5947DC.DB3AD4B2@mindspring.com> X-Url: http://www.nectar.cc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jan 31, 2002 at 05:34:20AM -0800, Terry Lambert wrote: > Uh... are you sure a cryptographic hash of the source > you have is going to give enough information for a > kernel hacker to recreate the binaries that are causing > the problem that resulted in the bug report? [snip] > 8-) 8-) 8-). The smileys indicate otherwise, but just in case: Maybe you missed the ``OK, you caught me. The last bullet was a joke.'' that followed my signature. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 7:51:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 4072C37B404; Thu, 31 Jan 2002 07:51:06 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0VFp0o27743; Thu, 31 Jan 2002 15:51:00 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 23C4ADC; Thu, 31 Jan 2002 15:50:12 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g0VCtUE69030; Thu, 31 Jan 2002 12:55:30 GMT (envelope-from mark@grondar.za) Message-Id: <200201311255.g0VCtUE69030@greenpeace.grondar.org> To: Ruslan Ermilov Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number References: <20020131144345.A73522@sunbay.com> In-Reply-To: <20020131144345.A73522@sunbay.com> ; from Ruslan Ermilov "Thu, 31 Jan 2002 14:43:45 +0200." Date: Thu, 31 Jan 2002 12:55:25 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > I don't think there are so many CVS meisters, or so much src repo > > surgery, that having them bump the serial number manually in these cases > > is a problem. > > "commit" is atomic operation, while direct manipulation of repository > isn't. To make it atomic, CVS meisters would have to lock src/, make > the necessary surgery, bump serial number, then unlock it. Don't worry. We know that stuff. > > 1) Folks reporting build failures can be asked to quote the serial > > number of the src tree they're building. > > > Mirroring of CVS repositories with CVSup could be a problem here. > We'd need to somehow guarantee that src/SERIAL is consistent with > the rest of the checked out sources. What if the mirror site you > are "cvs updating" from is experiencing a CVSup latency, and some > checked out sources are still behind SERIAL? This is not an > unlikely thing to see. There may be an inconsistancy, and that will usually(always?) be not much more than the time between updates plus the time to run one update, at maximum. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 7:51:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 0C41637B420; Thu, 31 Jan 2002 07:51:12 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0VFpBY27750; Thu, 31 Jan 2002 15:51:11 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 63624FD; Thu, 31 Jan 2002 15:50:12 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g0VCQmE68870; Thu, 31 Jan 2002 12:26:52 GMT (envelope-from mark@grondar.za) Message-Id: <200201311226.g0VCQmE68870@greenpeace.grondar.org> To: Ruslan Ermilov Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number References: <20020131140403.A69232@sunbay.com> In-Reply-To: <20020131140403.A69232@sunbay.com> ; from Ruslan Ermilov "Thu, 31 Jan 2002 14:04:03 +0200." Date: Thu, 31 Jan 2002 12:26:43 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This scheme won't work because the state of the tree can be modified > by CVS meisters performing direct operations on a repository. See > how stealthy the latest GCC import gone. A simple serial number which increases as the repo changes is sufficient. If the repo-meisters do surgery, then we need to also remember to bump the serial. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 7:53:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.dmnshq.net (vega.dmnshq.net [194.19.34.94]) by hub.freebsd.org (Postfix) with SMTP id 5ACDD37B404; Thu, 31 Jan 2002 07:53:06 -0800 (PST) Received: (from eivind@localhost) by phoenix.dmnshq.net (8.11.6/8.11.6) id g0VFqqt96774; Thu, 31 Jan 2002 16:52:52 +0100 (CET) (envelope-from eivind) Date: Thu, 31 Jan 2002 16:52:52 +0100 From: Eivind Eklund To: Ruslan Ermilov Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131165252.A96747@phoenix.dmnshq.net> References: <20020131140403.A69232@sunbay.com> <79636.1012479657@axl.seasidesoftware.co.za> <20020131144345.A73522@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020131144345.A73522@sunbay.com>; from ru@FreeBSD.ORG on Thu, Jan 31, 2002 at 02:43:45PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jan 31, 2002 at 02:43:45PM +0200, Ruslan Ermilov wrote: > On Thu, Jan 31, 2002 at 02:20:57PM +0200, Sheldon Hearn wrote: > > On Thu, 31 Jan 2002 14:04:03 +0200, Ruslan Ermilov wrote: > > > This scheme won't work because the state of the tree can be modified > > > by CVS meisters performing direct operations on a repository. See > > > how stealthy the latest GCC import gone. > > > > I don't think there are so many CVS meisters, or so much src repo > > surgery, that having them bump the serial number manually in these cases > > is a problem. > > "commit" is atomic operation, while direct manipulation of repository > isn't. To make it atomic, CVS meisters would have to lock src/, make > the necessary surgery, bump serial number, then unlock it. 'cvs commit' is non-atomic. We will not be able to get this to work perfectly with cvs and cvsup; both are non-atomic. We could make cvs atomic for our use, I guess, but I suspect we'd find that non-workable (as it would mean that we would get a lot more latency for any operations on the cvs tree). I still think a /usr/src/SERIAL would be nice; thought it would not give perfect information, it would still give better information than not having it. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8: 1:42 2002 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 D719637B43B for ; Thu, 31 Jan 2002 08:01:22 -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 g0VG0Ro36134; Thu, 31 Jan 2002 09:00:27 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0VG0Hx32133; Thu, 31 Jan 2002 09:00:21 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 08:59:38 -0700 (MST) Message-Id: <20020131.085938.18394797.imp@village.org> To: wes@softweyr.com Cc: tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, perry@wasabisystems.com, Todd.Miller@courtesan.com, deraadt@cvs.openbsd.org Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <3C58FBEC.746257BB@softweyr.com> References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm almost done with bin. I have a emacs macro to help me with __P() and have been doing the prototyping by hand, but it dawned on my that protoize may be the right tool here, so I'll be playing with that when I start up again. /bin/sh is the only thing I have left. Patches to be posted today or tomorrow. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8: 7:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from vagabond.auriga.ru (vagabond.auriga.ru [80.240.102.246]) by hub.freebsd.org (Postfix) with ESMTP id 7C63237B433 for ; Thu, 31 Jan 2002 08:07:32 -0800 (PST) Received: from localhost (localhost [[UNIX: localhost]]) by vagabond.auriga.ru (8.11.2/8.11.2) id g0VG7LB13373; Thu, 31 Jan 2002 19:07:21 +0300 Content-Type: text/plain; charset="iso-8859-1" From: "Alexey V. Neyman" To: Sheldon Hearn , Marco Molteni Subject: Re: Adding support for a global src tree serial number Date: Thu, 31 Jan 2002 19:07:20 +0300 X-Mailer: KMail [version 1.2] Cc: arch@FreeBSD.org References: <79603.1012479536@axl.seasidesoftware.co.za> In-Reply-To: <79603.1012479536@axl.seasidesoftware.co.za> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <0201311907200A.11434@vagabond.auriga.ru> Sender: owner-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 January 2002 15:18, Sheldon Hearn wrote: > [1] And anyway, do we really want to clutter the serial file with CVS > revision Id, which may cause confusion? Certainly, we won't be > allowing manual commits to this file! Please explain the behavior of this serial number at the time - when a minor release (like 4.5) is branched from -stable branch - when -current branch becomes -stable (branching 6.0-current) I really hope these serial numbers won't be interleaved (like #1 being related to -current, #2 to -stable and #3 again to -current) I'd suggest that every time a commit to src/ is made, this file would be checked out for appropriate branch (if it exists on that branch, of course - I doubt there's need of this file for NETGRAPH branch :-), incremented and checked-in. This way it will still have revision id, but the numbering of changes is quite simple - at every branchpoint all branches inherit the serial number. Regards, Alexey. -- <-------------------------> ) May the Sun and Water ( Regards, Alexey V. Neyman ) always fall upon you! ( mailto:alex.neyman@auriga.ru <-------------------------> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8:10:53 2002 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 5C14937B404; Thu, 31 Jan 2002 08:10:45 -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 g0VGAio36213; Thu, 31 Jan 2002 09:10:44 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0VGAgx32223; Thu, 31 Jan 2002 09:10:43 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 09:10:03 -0700 (MST) Message-Id: <20020131.091003.108028797.imp@village.org> To: ru@FreeBSD.ORG Cc: sheldonh@starjuice.net, arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number From: "M. Warner Losh" In-Reply-To: <20020131140403.A69232@sunbay.com> References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131140403.A69232@sunbay.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020131140403.A69232@sunbay.com> Ruslan Ermilov writes: : This scheme won't work because the state of the tree can be modified : by CVS meisters performing direct operations on a repository. See : how stealthy the latest GCC import gone. Also right now two committers can be committing to different parts of the tree at the same time, so A might get his src commit in first, but get the second serial because B races his commit in and wins the race for the global serial number. So the serial number is only approximately useful, but that approximation is likely to be better than 4.4 or 4.5 :-). Right now cvs co -D doesn't work due to repo surgeries, and this would be no different. As to the format, ignore everybody else and pick one that won't generate too many complaints. I have my opinions, but that's really a detail best left to the implementor. (eg I don't care what you do as long as it isn't Wrong :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8:12:39 2002 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 26AAE37B400 for ; Thu, 31 Jan 2002 08:12:32 -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 g0VGCUo36231; Thu, 31 Jan 2002 09:12:31 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0VGCUx32235; Thu, 31 Jan 2002 09:12:30 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 09:11:50 -0700 (MST) Message-Id: <20020131.091150.67419427.imp@village.org> To: sheldonh@starjuice.net Cc: molter@tin.it, arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number From: "M. Warner Losh" In-Reply-To: <79603.1012479536@axl.seasidesoftware.co.za> References: <20020131112850.GB28361@cobweb.example.org> <79603.1012479536@axl.seasidesoftware.co.za> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <79603.1012479536@axl.seasidesoftware.co.za> Sheldon Hearn writes: : Here, we use 4 digits to represent the year, 2 digits to represent the : month, 2 digits to represent the day and 7 digits to represent the : commit. This assumes that we would never see more than 999,999 commits : in a single day. I'm not sure this will happen before the year 10000AD. : ;-) Not even __P will cause this :-). : [1] And anyway, do we really want to clutter the serial file with CVS : revision Id, which may cause confusion? Certainly, we won't be : allowing manual commits to this file! We already have a mechanism for this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8:32:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from xerxes.courtesan.com (courtesan.com [206.168.103.86]) by hub.freebsd.org (Postfix) with ESMTP id 1359F37B417 for ; Thu, 31 Jan 2002 08:32:10 -0800 (PST) Received: from xerxes.courtesan.com (IDENT:millert@localhost.courtesan.com [127.0.0.1]) by xerxes.courtesan.com (8.12.2/8.12.1) with ESMTP id g0VGVPDx011045; Thu, 31 Jan 2002 09:31:25 -0700 (MST) Message-Id: <200201311631.g0VGVPDx011045@xerxes.courtesan.com> To: "M. Warner Losh" Cc: wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, perry@wasabisystems.com, deraadt@cvs.openbsd.org Subject: Re: __P macro question In-reply-to: Your message of "Thu, 31 Jan 2002 08:59:38 MST." <20020131.085938.18394797.imp@village.org> References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> Date: Thu, 31 Jan 2002 09:31:24 -0700 From: "Todd C. Miller" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A good way to check before vs. after may be to run things through cpp and compare the pre and post change with "diff -b". - todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8:43:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by hub.freebsd.org (Postfix) with ESMTP id 67FF437B400 for ; Thu, 31 Jan 2002 08:43:42 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 21584D97CA; Thu, 31 Jan 2002 11:43:41 -0500 (EST) From: "Perry E. Metzger" To: "M. Warner Losh" Cc: wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, Todd.Miller@courtesan.com, deraadt@cvs.openbsd.org Subject: Re: __P macro question References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> Date: 31 Jan 2002 11:43:41 -0500 In-Reply-To: <20020131.085938.18394797.imp@village.org> Message-ID: <87d6zq31z6.fsf@snark.piermont.com> Lines: 24 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 It might be bad for you to do this by hand. If you do it by hand, we'll get source diffs by accident. If we build a quick set of scripts to do it, since we'll all be using the same scripts, we'll end up with fewer diffs. .pm "M. Warner Losh" writes: > I'm almost done with bin. I have a emacs macro to help me with __P() > and have been doing the prototyping by hand, but it dawned on my that > protoize may be the right tool here, so I'll be playing with that when > I start up again. /bin/sh is the only thing I have left. Patches to > be posted today or tomorrow. > > Warner > -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8:55:40 2002 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 B97FA37B402 for ; Thu, 31 Jan 2002 08:55:06 -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 JAA17176; Thu, 31 Jan 2002 09:55:04 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0VGt2u14334; Thu, 31 Jan 2002 09:55:02 -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: <15449.30438.698921.182380@caddis.yogotech.com> Date: Thu, 31 Jan 2002 09:55:02 -0700 To: Sheldon Hearn Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: <80628.1012484102@axl.seasidesoftware.co.za> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> X-Mailer: VM 6.96 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 FWIW, this has been gone over many times in the past. We even had a workable solution, but unfortunately Richard W. (the originator of said feature request) refused to acknowledge the issues and propose a solution that would satisfy all problems. Some of the issues are: 1) A single static file is not adequate, becase we have multiple active branches. Therefore, each branch needs it's own file, and that file must only exist on that branch. 2) If a new branch is created, the system must recognize the new branch, and auto-create a new serial file for that branch. (Otherwise, it will be forgotten.) This is especially true with the new 'release product' branches. 3) That file must change at some frequency often-enough to be of use. Daily would probably be Ok, but more fine-grained would be better. 4) The file must exist in the /usr/src tree (and not in the CVS tree), since a large number of consumers do *NOT* grab the source tree, but still have the need to track the tree's age/history. (This implies that it must be some sort of RCS file.) 5) The file must not grow w/out bounds (which means that we'd have to play games if we used an RCS file above to keep things happy, and make sure that CVS/CVSup don't get all bent out of shape.) 6) The file must allow itself to be easily mirrored by CVSup, such that *all* consumers of FreeBSD who access the source tree can easily mirror the file. (Similar to 5) 7) The file must be in a format that can be queried by a tool, so that the user can easily identify the lineage of his/her source tree. Possibly create a new 'srcid(8)' or somesuch that can read the format of the file. The hardest problem are related to multiple branches and mirrored repositories. If we had a single repository and a single branch, the problem would be trivial. Unfortunately, we don't. The only solution we could come up with was a 'fake' RCS file that was hand-edited to increase the version # on a regular basis, and that a new 'branch' was added to this file everytime a new 'branch' was added to the tree. This means that the file would grow, but it would only grow as fast as we add branches. This isn't too bad. However, the hand-editing of the file, as well as auto-creation of new branches was a sticking point. I'm sure someone with lots of free time on their hands could probably implement something in the CVSROOT scripts to do this. At that point, we needed to verify that CVS/CVSup wouldn't have a cow. I think I did a quickie test, and any recent version CVS was fine with things (CVS 1.9 or later). I didn't check what CVSup would do with it though. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 8:59: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from xerxes.courtesan.com (courtesan.com [206.168.103.86]) by hub.freebsd.org (Postfix) with ESMTP id 2044E37B41A for ; Thu, 31 Jan 2002 08:58:58 -0800 (PST) Received: from xerxes.courtesan.com (IDENT:millert@localhost.courtesan.com [127.0.0.1]) by xerxes.courtesan.com (8.12.2/8.12.1) with ESMTP id g0VGwIDx006748; Thu, 31 Jan 2002 09:58:18 -0700 (MST) Message-Id: <200201311658.g0VGwIDx006748@xerxes.courtesan.com> To: "Perry E. Metzger" Cc: "M. Warner Losh" , wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question In-reply-to: Your message of "31 Jan 2002 11:43:41 EST." <87d6zq31z6.fsf@snark.piermont.com> References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> <87d6zq31z6.fsf@snark.piermont.com> Date: Thu, 31 Jan 2002 09:58:18 -0700 From: "Todd C. Miller" Sender: owner-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 <87d6zq31z6.fsf@snark.piermont.com> so spake "Perry E. Metzger" (perry): > If you do it by hand, we'll get source diffs by accident. If we build > a quick set of scripts to do it, since we'll all be using the same > scripts, we'll end up with fewer diffs. Speaking of which, what do folks think about things like: int f1 __P((int, char)); void f2 __P((long)); ie: where there is whitespace between the function name and the arguments. My inclination is to remove the extra whitespace during the conversion, like so: int f1(int, char); void f2(long); If we want to minimize useless whitespace differences it would be good if we all use the same scheme ;-) - todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 9: 0:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 2C0C337B416 for ; Thu, 31 Jan 2002 09:00:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020131170010.TTEG5382.rwcrmhc54.attbi.com@InterJet.elischer.org>; Thu, 31 Jan 2002 17:00:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id IAA61977; Thu, 31 Jan 2002 08:59:14 -0800 (PST) Date: Thu, 31 Jan 2002 08:59:13 -0800 (PST) From: Julian Elischer To: Sheldon Hearn Cc: Marco Molteni , arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number In-Reply-To: <79603.1012479536@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 Basically you are talking about an extension to the commit logging process. it would be good if the file also listed all files changed in that commit. On Thu, 31 Jan 2002, Sheldon Hearn wrote: > > > On Thu, 31 Jan 2002 12:28:50 +0100, Marco Molteni wrote: > > > the only drawback I see to your approach is that the serial number you are > > proposing is dateless, so folks will probably ask for a date too: > > > > > This problem was introduced in serial number 11809 and was > > > corrected in serial number 11832. > > I can see why support folks would want a date, however it's a trivial > thing to determine from the CVS logs for the src/SERIAL file. [1] > > That said, I can't think of any reason _not_ to prepend a date string to > the serial number. You said this: > > > One difference is that with your proposal two successive serial > > numbers have a difference of 1, for example 11833 - 11832 = 1, while > > with mine you loose this. > > But I can't see any value in knowing the number of commits made to the > entire tree between two snapshots. > > Another advantage of your idea is that it allows for a fixed-width > serial number until > > a) The year 10000AD. > > b) The number of commits (not deltas!) per day reaches an unexpectedly > high number. > > For example, we could say that the serial number should be constructed > as follows: > > YYYYMMDDXXXXXXX > 200201310000001 > > This example shows the first commit of the day for 31 January 2001 > (freefall time). > > Here, we use 4 digits to represent the year, 2 digits to represent the > month, 2 digits to represent the day and 7 digits to represent the > commit. This assumes that we would never see more than 999,999 commits > in a single day. I'm not sure this will happen before the year 10000AD. > ;-) > > Ciao, > Sheldon. > > [1] And anyway, do we really want to clutter the serial file with CVS > revision Id, which may cause confusion? Certainly, we won't be > allowing manual commits to this file! > > 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 Jan 31 9:10:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tomts14-srv.bellnexxia.net (tomts14.bellnexxia.net [209.226.175.35]) by hub.freebsd.org (Postfix) with ESMTP id 7A2EE37B402 for ; Thu, 31 Jan 2002 09:10:43 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.186.7]) by tomts14-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20020131171042.HGAM29652.tomts14-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Thu, 31 Jan 2002 12:10:42 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id 3D432189F; Thu, 31 Jan 2002 12:10:37 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id 51B1D20ACC; Thu, 31 Jan 2002 12:10:36 -0500 (EST) Date: Thu, 31 Jan 2002 12:10:36 -0500 From: The Anarcat To: "Jacques A. Vidrine" Cc: Sheldon Hearn , arch@FreeBSD.org Subject: tee versionning in npkg (Re: Adding support for a global src tree serial number) Message-ID: <20020131171036.GA295@shall.anarcat.dyndns.org> References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20020131131714.GA87780@madman.nectar.cc> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu Jan 31, 2002 at 07:17:15AM -0600, Jacques A. Vidrine wrote: > On Thu, Jan 31, 2002 at 01:01:38PM +0200, Sheldon Hearn wrote: > > I'd like to propose the addition of a global src tree serial number that > > uniquely identifies an imaginary snapshot of the src tree. >=20 > This is attractive to me, since we already do something like this for > the `security' branches (RELENG_4_3 et al). We manually bump $BRANCH > in newvers.sh. I imagine it would also be attractive to people on > freebsd-binup. [with my libh developper hat on] I can't talk in the name of the binup project, since i'm not particularly involved in his developpment, but as for the next-generation package system and installation tools (libh), my idea of it is that it will be more modular than a single package with a single version number for the whole tree. The libh package system still needs some work, but when it is ready, I will start the packaging of /usr/src. I hope the tendency will not to package it as a single package, and I even hope to package it as finer-grained package than current "distributions" (bin, doc, contrib, etc). Something more like: fileutils, binutils, gnu-binutils, openssh, openssl, etc. These packages will all have independant package numbers. These will have to be maintained, somehow, and this is the main problem of the packaging of /usr/src: it is not made for that yet. No support is engineered in /usr/src to allow distribution and versionning of packages. Serial number is one thing, and it might be a good idea, but we could also consider more "classic" version numbers for sub-trees, as openssh-2001013109910000008 is not really a "user-friendly" package name. :) A. --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZeosACgkQttcWHAnWiGe5mQCfUPIWxhNyOT6kIe7EwuTjxLiw OmEAn22DFcSq6Q0bpAv0toVSwMWkOPrt =bhe2 -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 9:26:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 5EF9B37B417 for ; Thu, 31 Jan 2002 09:26:12 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g0VHQ9M19110; Thu, 31 Jan 2002 09:26:09 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g0VHQ9701193; Thu, 31 Jan 2002 09:26:09 -0800 (PST) (envelope-from jdp) Date: Thu, 31 Jan 2002 09:26:09 -0800 (PST) Message-Id: <200201311726.g0VHQ9701193@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Cc: sheldonh@starjuice.net Subject: Re: Adding support for a global src tree serial number In-Reply-To: <79909.1012481992@axl.seasidesoftware.co.za> References: <79909.1012481992@axl.seasidesoftware.co.za> Organization: Polstra & Co., Seattle, WA Sender: owner-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 <79909.1012481992@axl.seasidesoftware.co.za>, Sheldon Hearn wrote: > > I didn't realize that cvsup mirrors might offer me a src/bin that's > newer than the src/sbin that it offers me (for example). Yes, that's what would happen, except most likely in reverse. CVSup processes the tree in alphabetical order. But I object to this idea for a different reason. Every day a large number of commits are made to the src tree. You are proposing that every one of those commits would add a delta to the serial number file. That file would soon have tens of thousands of deltas. That makes it quite inefficient for both cvs and CVSup. This idea simply doesn't scale to the long-term. If you want a serial number file, I wouldn't mind if it got a commit, say, once a week or maybe even once a day. But to do it on every change to the src tree is overkill. CVSup already grabs a timestamp from the server when it begins to update each new collection. In my copious spare time I am working on making this timestamp propagate through multiple levels of mirrors so it will be available to clients. CVSup could store that timestamp somewhere for future reference. I could also make it get a timestamp at the _end_ of each collection. Then each user would receive a fairly narrow time window (one minute or so) with a guarantee that all file versions came from within that window. That seems like a much more reasonable solution than an ever-growing serial number file. John PS - I changed the from address because I don't want to be on the cc of a long thread. Don't add me back. I'll read this stuff in freebsd-arch. And don't lecture me about procmail, because I know exactly what I'm doing. :-) -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 9:37: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 18C8137B400 for ; Thu, 31 Jan 2002 09:37:04 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 97A10F7; Thu, 31 Jan 2002 17:37:02 +0000 (GMT) Date: Thu, 31 Jan 2002 17:37:02 +0000 From: Josef Karthauser To: Nate Williams Cc: Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131173702.J77899@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GlnCQLZWzqLRJED8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15449.30438.698921.182380@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 31, 2002 at 09:55:02AM -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 --GlnCQLZWzqLRJED8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 31, 2002 at 09:55:02AM -0700, Nate Williams wrote: > FWIW, this has been gone over many times in the past. We even had a > workable solution, but unfortunately Richard W. (the originator of said > feature request) refused to acknowledge the issues and propose a > solution that would satisfy all problems. This is mad! :) The easiest solution is the one that I proposed in the PR, which is to use the effective date of the latest date in the $FreeBSD$ files. Of course this means going through each source file, but that's only time. Doing anything with CVSROOT/ and cvsup, etc, is complexity that isn't needed. l=`find /usr/src/sys | xargs grep '\$FreeBSD:.*$' | sed \ 's/.*\$FreeBSD://' | awk '{ print $3 "-" $4 }' | sort -n | tail -1` Kind of thing. Joe --GlnCQLZWzqLRJED8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZgL0ACgkQXVIcjOaxUBYAFQCgsjJIbkobqPkNxYNz/7FOCYXa b8cAn3ABMxSOImzj1n6nxW71qAfIZFwH =bpIy -----END PGP SIGNATURE----- --GlnCQLZWzqLRJED8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 9:40:35 2002 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 278A537B400 for ; Thu, 31 Jan 2002 09:40:29 -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 KAA18956; Thu, 31 Jan 2002 10:40:20 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0VHeI514967; Thu, 31 Jan 2002 10:40: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: <15449.33154.45261.703514@caddis.yogotech.com> Date: Thu, 31 Jan 2002 10:40:18 -0700 To: Josef Karthauser Cc: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: <20020131173702.J77899@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> X-Mailer: VM 6.96 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 > > FWIW, this has been gone over many times in the past. We even had a > > workable solution, but unfortunately Richard W. (the originator of said > > feature request) refused to acknowledge the issues and propose a > > solution that would satisfy all problems. > > This is mad! :) > > The easiest solution is the one that I proposed in the PR, which is to > use the effective date of the latest date in the $FreeBSD$ files. Won't work. > Of course this means going through each source file, but that's only > time. Time is a precious commodity, especially when you talk the entire tree. Plus, each user may have a different subset of the tree (some wouldn't have kerberos, some wouldn't have doc, some wouldn't have release, etc...) No standard. > Doing anything with CVSROOT/ and cvsup, etc, is complexity that > isn't needed. > > l=`find /usr/src/sys | xargs grep '\$FreeBSD:.*$' | sed \ > 's/.*\$FreeBSD://' | awk '{ print $3 "-" $4 }' | sort -n | tail -1` > > Kind of thing. Way too much overhead and you wouldn't get a consistent answer. Kind of like going to buying a hardware store just to hammer in a nail. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 9:50: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id CB4B937B404 for ; Thu, 31 Jan 2002 09:50:05 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id BC144F7; Thu, 31 Jan 2002 17:50:01 +0000 (GMT) Date: Thu, 31 Jan 2002 17:50:01 +0000 From: Josef Karthauser To: Nate Williams Cc: Josef Karthauser , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131175001.K77899@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <15449.33154.45261.703514@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2feizKym29CxAecD" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15449.33154.45261.703514@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 31, 2002 at 10:40:18AM -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 --2feizKym29CxAecD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2002 at 10:40:18AM -0700, Nate Williams wrote: > > > FWIW, this has been gone over many times in the past. We even had a > > > workable solution, but unfortunately Richard W. (the originator of sa= id > > > feature request) refused to acknowledge the issues and propose a > > > solution that would satisfy all problems. > >=20 > > This is mad! :) > >=20 > > The easiest solution is the one that I proposed in the PR, which is to > > use the effective date of the latest date in the $FreeBSD$ files. >=20 > Won't work. Does work. There is always a latest commit in the source tree. =20 > > Of course this means going through each source file, but that's only > > time. >=20 > Time is a precious commodity, especially when you talk the entire tree. > Plus, each user may have a different subset of the tree (some wouldn't > have kerberos, some wouldn't have doc, some wouldn't have release, > etc...) >=20 > No standard. There is a standard src tree though. > > Doing anything with CVSROOT/ and cvsup, etc, is complexity that > > isn't needed. > >=20 > > l=3D`find /usr/src/sys | xargs grep '\$FreeBSD:.*$' | sed \ > > 's/.*\$FreeBSD://' | awk '{ print $3 "-" $4 }' | sort -n | tail -1` > >=20 > > Kind of thing. >=20 > Way too much overhead and you wouldn't get a consistent answer. Kind of > like going to buying a hardware store just to hammer in a nail. :) Why wouldn't you get a consistent answer. A source tree is a source tree isn't it? Joe --2feizKym29CxAecD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZg8kACgkQXVIcjOaxUBY24gCgqO45//ob8lscLpSIzo4kLrdI V5UAnjV2Vc4rcjaMCIONt4G8pHLkL1g+ =OO6q -----END PGP SIGNATURE----- --2feizKym29CxAecD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 9:56:54 2002 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 1D19537B419 for ; Thu, 31 Jan 2002 09:56:30 -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 KAA19578; Thu, 31 Jan 2002 10:56:20 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0VHuGC15093; Thu, 31 Jan 2002 10:56:16 -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: <15449.34112.10169.928474@caddis.yogotech.com> Date: Thu, 31 Jan 2002 10:56:16 -0700 To: Josef Karthauser Cc: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: <20020131175001.K77899@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <15449.33154.45261.703514@caddis.yogotech.com> <20020131175001.K77899@genius.tao.org.uk> X-Mailer: VM 6.96 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 > > > > FWIW, this has been gone over many times in the past. We even had a > > > > workable solution, but unfortunately Richard W. (the originator of said > > > > feature request) refused to acknowledge the issues and propose a > > > > solution that would satisfy all problems. > > > > > > This is mad! :) > > > > > > The easiest solution is the one that I proposed in the PR, which is to > > > use the effective date of the latest date in the $FreeBSD$ files. > > > > Won't work. > > Does work. There is always a latest commit in the source tree. > > > > Of course this means going through each source file, but that's only > > > time. > > > > Time is a precious commodity, especially when you talk the entire tree. > > Plus, each user may have a different subset of the tree (some wouldn't > > have kerberos, some wouldn't have doc, some wouldn't have release, > > etc...) > > > > No standard. > > There is a standard src tree though. I disagree. See above. > > > Doing anything with CVSROOT/ and cvsup, etc, is complexity that > > > isn't needed. > > > > > > l=`find /usr/src/sys | xargs grep '\$FreeBSD:.*$' | sed \ > > > 's/.*\$FreeBSD://' | awk '{ print $3 "-" $4 }' | sort -n | tail -1` > > > > > > Kind of thing. > > > > Way too much overhead and you wouldn't get a consistent answer. Kind of > > like going to buying a hardware store just to hammer in a nail. :) > > Why wouldn't you get a consistent answer. A source tree is a source > tree isn't it? Nope. I don't have alpha/pc98/sparc/ia64 bits in my x86 tree. I don't have any need for them, so why have them fill up my tree. On my alpha, I don't have the non-relevant bits as well. In short, unless you *define* a standard ahead of time, you can't guarantee a consistent answer. And, it still takes *way* too long to calculate. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:20:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id B60F137B402; Thu, 31 Jan 2002 10:20:14 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 06EE22F6; Thu, 31 Jan 2002 18:20:14 +0000 (GMT) Date: Thu, 31 Jan 2002 18:20:13 +0000 From: Josef Karthauser To: Mark Murray Cc: Ruslan Ermilov , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131182013.A84715@genius.tao.org.uk> References: <20020131140403.A69232@sunbay.com> <200201311226.g0VCQmE68870@greenpeace.grondar.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201311226.g0VCQmE68870@greenpeace.grondar.org>; from mark@grondar.za on Thu, Jan 31, 2002 at 12:26:43PM +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 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2002 at 12:26:43PM +0000, Mark Murray wrote: > > This scheme won't work because the state of the tree can be modified > > by CVS meisters performing direct operations on a repository. See > > how stealthy the latest GCC import gone. >=20 > A simple serial number which increases as the repo changes is > sufficient. If the repo-meisters do surgery, then we need to > also remember to bump the serial. A serial number in /home/ncvs/src/SERIAL wouldn't even need to be kept under revision control as cvsup will still transfer it. (On the other hand those of us that use cvs to update the source would miss out). Joe --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZit0ACgkQXVIcjOaxUBalUQCbBsdH9GJFUNjT33AYLniHB4h0 nNYAn1pKy4TxE5A2Cvic7Di8ut6Xkpsq =FRYc -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:22:51 2002 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 95C4A37B416 for ; Thu, 31 Jan 2002 10:22:46 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 97B3A5341; Thu, 31 Jan 2002 19:22:37 +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: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> From: Dag-Erling Smorgrav Date: 31 Jan 2002 19:22:36 +0100 In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 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 Sheldon Hearn writes: > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. Yes, I totally agree that we should switch to Perforce. DES (ducks, runs) -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:28:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 9FBB937B400 for ; Thu, 31 Jan 2002 10:28:40 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id EACB92F6; Thu, 31 Jan 2002 18:28:39 +0000 (GMT) Date: Thu, 31 Jan 2002 18:28:39 +0000 From: Josef Karthauser To: Nate Williams Cc: Josef Karthauser , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131182839.B84715@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <15449.33154.45261.703514@caddis.yogotech.com> <20020131175001.K77899@genius.tao.org.uk> <15449.34112.10169.928474@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15449.34112.10169.928474@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 31, 2002 at 10:56:16AM -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 --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2002 at 10:56:16AM -0700, Nate Williams wrote: >=20 > > Why wouldn't you get a consistent answer. A source tree is a source > > tree isn't it? >=20 > Nope. I don't have alpha/pc98/sparc/ia64 bits in my x86 tree. I don't > have any need for them, so why have them fill up my tree. On my alpha, > I don't have the non-relevant bits as well. >=20 > In short, unless you *define* a standard ahead of time, you can't > guarantee a consistent answer. >=20 > And, it still takes *way* too long to calculate. >=20 Maybe we're talking about different things. The point of having a kernel version date that is related to the source and not to the build-date is to have an idea of what source versions might contribute to a bug. It doesn't matter whether all the source is there or not, whether they're alpha/pc98/sparc or whatever. If we use latest date in a $FreeBSD$ tag of the source files that are installed by submitting the output of 'uname -v' and a kernel config file it's possible to know the latest change in the repository that might have caused a problem. That solves the problem surely. % uname -v FreeBSD 5.0-CURRENT[20011101-12:01:00] #0: Tue Jan 22 09:46:56 GMT 2002 = joe@genius.tao.org.uk:/usr/obj/usr/src/sys/GENIUS=20 This clearly says that the latest change in the repository that could make a difference was on Nov 1st 2001. The Jan 22 date is totally arbitrary. Also it doesn't take too long to do a find across src/sys, compared with the amount of time it takes to build the source. For most users they won't notice it; for power users like us we can switch it off in /etc/make.conf and save the time. Joe --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZjNcACgkQXVIcjOaxUBbWLQCgjJhLoKXTVfmLTNMhMYR9QtKI CxcAoKChADFPOeCJab9dK+a7o3FoRKhX =H7BH -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:31:28 2002 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 D87D737B402 for ; Thu, 31 Jan 2002 10:31:22 -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 LAA20976; Thu, 31 Jan 2002 11:31:18 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0VIVI915384; Thu, 31 Jan 2002 11:31: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: <15449.36214.123443.928826@caddis.yogotech.com> Date: Thu, 31 Jan 2002 11:31:18 -0700 To: Josef Karthauser Cc: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: <20020131182839.B84715@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <15449.33154.45261.703514@caddis.yogotech.com> <20020131175001.K77899@genius.tao.org.uk> <15449.34112.10169.928474@caddis.yogotech.com> <20020131182839.B84715@genius.tao.org.uk> X-Mailer: VM 6.96 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 wouldn't you get a consistent answer. A source tree is a source > > > tree isn't it? > > > > Nope. I don't have alpha/pc98/sparc/ia64 bits in my x86 tree. I don't > > have any need for them, so why have them fill up my tree. On my alpha, > > I don't have the non-relevant bits as well. > > > > In short, unless you *define* a standard ahead of time, you can't > > guarantee a consistent answer. > > > > And, it still takes *way* too long to calculate. > > > > Maybe we're talking about different things. The point of having a > kernel version date that is related to the source and not to the > build-date is to have an idea of what source versions might contribute > to a bug. Agreed. But, I don't think we should limit it to just kernel, since there are non-kernel bugs, and it would be nice to know how they work. > It doesn't matter whether all the source is there or > not, whether they're alpha/pc98/sparc or whatever. If we use latest > date in a $FreeBSD$ tag of the source files that are installed by > submitting the output of 'uname -v' and a kernel config file it's > possible to know the latest change in the repository that might > have caused a problem. That solves the problem surely. > > % uname -v > FreeBSD 5.0-CURRENT[20011101-12:01:00] #0: Tue Jan 22 09:46:56 GMT 2002 joe@genius.tao.org.uk:/usr/obj/usr/src/sys/GENIUS > > This clearly says that the latest change in the repository that > could make a difference was on Nov 1st 2001. The Jan 22 date is > totally arbitrary. How do you get Nov 1 from the above? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:33:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.yadt.co.uk (yadt.demon.co.uk [158.152.4.134]) by hub.freebsd.org (Postfix) with SMTP id 1FC1C37B419 for ; Thu, 31 Jan 2002 10:33:27 -0800 (PST) Received: (qmail 49583 invoked from network); 31 Jan 2002 18:33:23 -0000 Received: from unknown (HELO mail.gattaca.yadt.co.uk) (qmailr@10.0.0.2) by yadt.demon.co.uk with SMTP; 31 Jan 2002 18:33:23 -0000 Received: (qmail 61225 invoked by uid 1000); 31 Jan 2002 18:33:21 -0000 Date: Thu, 31 Jan 2002 18:33:21 +0000 From: David Taylor To: Josef Karthauser Cc: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131183321.GA59544@gattaca.yadt.co.uk> Mail-Followup-To: Josef Karthauser , Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20020131173702.J77899@genius.tao.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 31 Jan 2002, Josef Karthauser wrote: > On Thu, Jan 31, 2002 at 09:55:02AM -0700, Nate Williams wrote: > > FWIW, this has been gone over many times in the past. We even had a > > workable solution, but unfortunately Richard W. (the originator of said > > feature request) refused to acknowledge the issues and propose a > > solution that would satisfy all problems. >=20 > This is mad! :) >=20 > The easiest solution is the one that I proposed in the PR, which is to > use the effective date of the latest date in the $FreeBSD$ files. > Of course this means going through each source file, but that's only > time. Doing anything with CVSROOT/ and cvsup, etc, is complexity that > isn't needed. The ircd-hybrid CVS repo is currently using a copy of the FreeBSD CVSROOT/ scripts (thanks for those! :), with various modifications to maintain the behaviour of the previous scripts. One modification I made was to create a (reverse order) ChangeLog file, (I added a 'POSTLOG_SUB($logfile)' config option, which, if the log name matched ($foo) =3D /(.*)\.tmp$/, would append "$foo" to "$foo.tmp" and rena= me it "$foo", but I'm sure there's a nicer way to do it). The other, was a commit 'serial number', in the format YYYYMMDD_, where is incremented by one for each commit, and reset to 0 each day. I did that by adding 'PRELOG_SUB($file, @text)' (Uhm, actually, I suspect that already exists, I just abused it) which (hackishly) also checks the logfile name against /.*\.tmp$/ to decide if it should do a serial number or not. Then it just determines the name of the serial file from the ChangeLog file (e.g. ircd-hybrid-7/ChangeLog -> ircd-hybrid-7/include/serno.h), and uses co -l/ci -mfoo to update the file, with some perl-foo to update the number inbetween, of course). It'd be easy(ish) to create a specific option to update a configurable serno for each repo, instead of overloading the log filename for everything. The file created by the script just looks like #define SERIALNUM "20020122_1" So the file is just #include'd where needed. I also added the serialnum to the commit mail. > l=3D`find /usr/src/sys | xargs grep '\$FreeBSD:.*$' | sed \ > 's/.*\$FreeBSD://' | awk '{ print $3 "-" $4 }' | sort -n | tail -1` That can take ages, and isn't necesarily correct if parts of src/ aren't present. I thought the idea was for a quickly obtainable number that can be included with PRs, and stored inside the kernel or whatever. --=20 David Taylor davidt@yadt.co.uk "The future just ain't what it used to be" --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8WY3xfIqKXSsJ/xERAsSLAKDFaxViwo67NOEda+Lj9k9CnGDduwCgiblZ G8EJUhXn+SqfQbXdL+KZ0Lk= =10M7 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:36:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 6A32E37B41D for ; Thu, 31 Jan 2002 10:36:19 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 9D1A22F6; Thu, 31 Jan 2002 18:36:18 +0000 (GMT) Date: Thu, 31 Jan 2002 18:36:18 +0000 From: Josef Karthauser To: Nate Williams Cc: Josef Karthauser , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131183618.C84715@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <15449.33154.45261.703514@caddis.yogotech.com> <20020131175001.K77899@genius.tao.org.uk> <15449.34112.10169.928474@caddis.yogotech.com> <20020131182839.B84715@genius.tao.org.uk> <15449.36214.123443.928826@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15449.36214.123443.928826@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 31, 2002 at 11:31:18AM -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 --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2002 at 11:31:18AM -0700, Nate Williams wrote: > > Maybe we're talking about different things. The point of having a > > kernel version date that is related to the source and not to the > > build-date is to have an idea of what source versions might contribute > > to a bug. >=20 > Agreed. But, I don't think we should limit it to just kernel, since > there are non-kernel bugs, and it would be nice to know how they work. Of course. The kernel is a good place to start though. The date in uname -v isn't particularly helpful at the moment. Userland issues are clouded by the fact that each piece of software is discrete. Also we have 'ident' which can tell us about any particular piece of software. We could almost do a ident-extract-latest-date in periodic to deal with userland. > > It doesn't matter whether all the source is there or > > not, whether they're alpha/pc98/sparc or whatever. If we use latest > > date in a $FreeBSD$ tag of the source files that are installed by > > submitting the output of 'uname -v' and a kernel config file it's > > possible to know the latest change in the repository that might > > have caused a problem. That solves the problem surely. > >=20 > > % uname -v > > FreeBSD 5.0-CURRENT[20011101-12:01:00] #0: Tue Jan 22 09:46:56 GMT 2002= joe@genius.tao.org.uk:/usr/obj/usr/src/sys/GENIUS=20 > >=20 > > This clearly says that the latest change in the repository that > > could make a difference was on Nov 1st 2001. The Jan 22 date is > > totally arbitrary. >=20 > How do you get Nov 1 from the above? The date after the 5.0-CURRENT bit. (Proof of concept, not final uname format). Joe --Bu8it7iiRSEf40bY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZjqIACgkQXVIcjOaxUBbxCgCfTXl2BnJeNIh40TxfSMMQIWCx rzYAoOrAeGu6lavf5ptbR45hAGxWmH+b =ITvM -----END PGP SIGNATURE----- --Bu8it7iiRSEf40bY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:41:32 2002 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 AE0DE37B417 for ; Thu, 31 Jan 2002 10:41:24 -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 LAA21411; Thu, 31 Jan 2002 11:41:18 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0VIfFH15471; Thu, 31 Jan 2002 11:41:15 -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: <15449.36811.343058.246674@caddis.yogotech.com> Date: Thu, 31 Jan 2002 11:41:15 -0700 To: Josef Karthauser Cc: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: <20020131183618.C84715@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <15449.33154.45261.703514@caddis.yogotech.com> <20020131175001.K77899@genius.tao.org.uk> <15449.34112.10169.928474@caddis.yogotech.com> <20020131182839.B84715@genius.tao.org.uk> <15449.36214.123443.928826@caddis.yogotech.com> <20020131183618.C84715@genius.tao.org.uk> X-Mailer: VM 6.96 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 > > > Maybe we're talking about different things. The point of having a > > > kernel version date that is related to the source and not to the > > > build-date is to have an idea of what source versions might contribute > > > to a bug. > > > > Agreed. But, I don't think we should limit it to just kernel, since > > there are non-kernel bugs, and it would be nice to know how they work. > > Of course. The kernel is a good place to start though. The date in > uname -v isn't particularly helpful at the moment. Agreed. > Userland issues > are clouded by the fact that each piece of software is discrete. And, it's not just a binary software issue. Configuration files that change, etc... > Also > we have 'ident' which can tell us about any particular piece of > software. We could almost do a ident-extract-latest-date in periodic > to deal with userland. See above. Ident doesn't give a snapshot of the entire system. Having a global serial # for the system is a better thing in terms of user support, IMO. (It could be included in PR reports). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:42:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 6511737B419 for ; Thu, 31 Jan 2002 10:42:31 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 6289632B; Thu, 31 Jan 2002 18:42:30 +0000 (GMT) Date: Thu, 31 Jan 2002 18:42:30 +0000 From: Josef Karthauser To: Josef Karthauser , Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131184230.D84715@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="hxkXGo8AKqTJ+9QI" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020131183321.GA59544@gattaca.yadt.co.uk>; from davidt@yadt.co.uk on Thu, Jan 31, 2002 at 06:33:21PM +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 --hxkXGo8AKqTJ+9QI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2002 at 06:33:21PM +0000, David Taylor wrote: >=20 > #define SERIALNUM "20020122_1" >=20 > So the file is just #include'd where needed. The problem is where to put the serial number, and how to distribute it. It needs to be maintained in a ,v file for cvs to be able to check it out. That adds additional complexity. > I also added the serialnum to the commit mail. >=20 > > l=3D`find /usr/src/sys | xargs grep '\$FreeBSD:.*$' | sed \ > > 's/.*\$FreeBSD://' | awk '{ print $3 "-" $4 }' | sort -n | tail -1` >=20 > That can take ages, and isn't necesarily correct if parts of src/ aren't > present. I thought the idea was for a quickly obtainable number that can > be included with PRs, and stored inside the kernel or whatever. It's correct enough to give a the "effect latest source" date for a particular kernel build irrespective of what parts of the tree are there. It doesn't matter if alpha/ has been committed to more recently if that source isn't being used in this kernel. Also, it doesn't take "ages". It takes a little while, but not ages. Joe --hxkXGo8AKqTJ+9QI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZkBUACgkQXVIcjOaxUBaINQCg4FHth7kxM7C+SzYTnnOUSXMa U70An0zrhVqiSFC9Ol4LVLqVB/3YOSKQ =jou+ -----END PGP SIGNATURE----- --hxkXGo8AKqTJ+9QI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 10:51:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.yadt.co.uk (yadt.demon.co.uk [158.152.4.134]) by hub.freebsd.org (Postfix) with SMTP id 253EE37B402 for ; Thu, 31 Jan 2002 10:51:16 -0800 (PST) Received: (qmail 49732 invoked from network); 31 Jan 2002 18:51:01 -0000 Received: from unknown (HELO mail.gattaca.yadt.co.uk) (qmailr@10.0.0.2) by yadt.demon.co.uk with SMTP; 31 Jan 2002 18:51:01 -0000 Received: (qmail 61749 invoked by uid 1000); 31 Jan 2002 18:51:00 -0000 Date: Thu, 31 Jan 2002 18:51:00 +0000 From: David Taylor To: Josef Karthauser Cc: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131185100.GA61302@gattaca.yadt.co.uk> Mail-Followup-To: Josef Karthauser , Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20020131184230.D84715@genius.tao.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --KsGdsel6WgEHnImy Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 31 Jan 2002, Josef Karthauser wrote: > On Thu, Jan 31, 2002 at 06:33:21PM +0000, David Taylor wrote: > >=20 > > #define SERIALNUM "20020122_1" > >=20 > > So the file is just #include'd where needed. >=20 > The problem is where to put the serial number, and how to distribute it. > It needs to be maintained in a ,v file for cvs to be able to check it > out. That adds additional complexity. As I said above in the part you snipped, I added a PRELOG_SUB which I used to call 'co -l serno.h', modify serno.h, then call 'ci -mautomated_serno serno.h'. Alternatively, you could make the script alter the ,v file directly and just call 'co' to try to keep the number of useless diffs down. I'm not sure if cvs likes just having one revision of a file at revision 1.9999999 in a ,v file, though. =20 > > That can take ages, and isn't necesarily correct if parts of src/ aren't > > present. I thought the idea was for a quickly obtainable number that c= an > > be included with PRs, and stored inside the kernel or whatever. >=20 > It's correct enough to give a the "effect latest source" date for > a particular kernel build irrespective of what parts of the tree > are there. It doesn't matter if alpha/ has been committed to more > recently if that source isn't being used in this kernel. True. =20 > Also, it doesn't take "ages". It takes a little while, but not ages. Takes ages on my gateway... admittedly a buildworld does too, but I don't want to add a 'find /usr/src' to my PR info-gathering tasks.. --=20 David Taylor davidt@yadt.co.uk "The future just ain't what it used to be" --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8WZIUfIqKXSsJ/xERAs1xAJ9kggX6GMigqStOhqwb+JVJYsAAEACg0pxf +GvjnkwP9awfZWlA8PPlqew= =9jlc -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 11: 8:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 0E4B037B417 for ; Thu, 31 Jan 2002 11:08:51 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 3EFDA441; Thu, 31 Jan 2002 19:08:50 +0000 (GMT) Date: Thu, 31 Jan 2002 19:08:50 +0000 From: Josef Karthauser To: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131190850.D85753@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> <20020131185100.GA61302@gattaca.yadt.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="9dgjiU4MmWPVapMU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020131185100.GA61302@gattaca.yadt.co.uk>; from davidt@yadt.co.uk on Thu, Jan 31, 2002 at 06:51:00PM +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 --9dgjiU4MmWPVapMU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2002 at 06:51:00PM +0000, David Taylor wrote: >=20 > As I said above in the part you snipped, I added a PRELOG_SUB which I used > to call 'co -l serno.h', modify serno.h, then call > 'ci -mautomated_serno serno.h'. >=20 > Alternatively, you could make the script alter the ,v file directly and > just call 'co' to try to keep the number of useless diffs down. I'm not > sure if cvs likes just having one revision of a file at revision > 1.9999999 in a ,v file, though. > It's probably worth playing with. I might put some time into seeing how it pans out. The proof is in the implementation. (Feel free to send me your patches to CVSROOT/, but off list). >=20 > Takes ages on my gateway... admittedly a buildworld does too, but I don't > want to add a 'find /usr/src' to my PR info-gathering tasks.. >=20 No, the point of the patch is that this is done for you automatically at kernel build time and the date is built into the version string that you get using 'uname -v'. i.e. it's transparent to the process. Joe --9dgjiU4MmWPVapMU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZlkEACgkQXVIcjOaxUBbZiwCdFg9MnAK6Hv3BeWllq6b+rzX4 aGgAoNA8RSAZddo6YT/gfVnYctQR+ad+ =kva+ -----END PGP SIGNATURE----- --9dgjiU4MmWPVapMU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 11:17:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 168F737B402 for ; Thu, 31 Jan 2002 11:17:33 -0800 (PST) Received: (qmail 76419 invoked by uid 1000); 31 Jan 2002 19:17:54 -0000 Date: Thu, 31 Jan 2002 11:17:32 -0800 From: Jos Backus To: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131191754.GB75898@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: arch@FreeBSD.org References: <79300.1012474898@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i Sender: owner-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, Jan 31, 2002 at 07:22:36PM +0100, Dag-Erling Smorgrav wrote: > Yes, I totally agree that we should switch to Perforce. Subversion? All current CVS features. CVS is good, as far as it goes, so we want to keep feature-compatibility: versioning, folding of non-conflicting changes, detection of conflicting changes, branching, merging, historical diffs, log messages, line-by-line history (cvs annotate), etc. Generally, Subversion's conceptual interface to a particular feature will be as similar to CVS's as possible, except where there's a compelling reason to do otherwise. Commits are truly atomic. No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file. http://subversion.tigris.org/ (Just kidding, of course.) -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 11:21:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 1CCF337B404 for ; Thu, 31 Jan 2002 11:21:29 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0VJKLW31819; Thu, 31 Jan 2002 19:20:21 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 8DC1C365; Thu, 31 Jan 2002 19:20:14 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g0VJJvE72037; Thu, 31 Jan 2002 19:19:59 GMT (envelope-from mark@grondar.za) Message-Id: <200201311919.g0VJJvE72037@greenpeace.grondar.org> To: "Todd C. Miller" Cc: "Perry E. Metzger" , "M. Warner Losh" , wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question References: <200201311658.g0VGwIDx006748@xerxes.courtesan.com> In-Reply-To: <200201311658.g0VGwIDx006748@xerxes.courtesan.com> ; from "Todd C. Miller" "Thu, 31 Jan 2002 09:58:18 MST." Date: Thu, 31 Jan 2002 19:19:52 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Said "Perry E. Metzger" (perry): > ie: where there is whitespace between the function name and the > arguments. My inclination is to remove the extra whitespace during > the conversion, like so: > int f1(int, char); > void f2(long); Our approach has been to remove the whitespace, as you have it above. > If we want to minimize useless whitespace differences it would be > good if we all use the same scheme ;-) Zigactly! M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 11:22:24 2002 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 1DD9337B404 for ; Thu, 31 Jan 2002 11:22:22 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0VJM1Y01522; Thu, 31 Jan 2002 11:22:01 -0800 (PST) (envelope-from obrien) Date: Thu, 31 Jan 2002 11:22:01 -0800 From: "David O'Brien" To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131112201.A1475@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <79300.1012474898@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Thu, Jan 31, 2002 at 01:01:38PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jan 31, 2002 at 01:01:38PM +0200, Sheldon Hearn wrote: > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. This really isn't arch related materal. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 11:25:58 2002 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 F377537B416 for ; Thu, 31 Jan 2002 11:25:54 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0VJPnu01544 for arch@freebsd.org; Thu, 31 Jan 2002 11:25:49 -0800 (PST) (envelope-from obrien) Date: Thu, 31 Jan 2002 11:25:49 -0800 From: "David O'Brien" To: John Polstra Subject: new sig + Sparc (was Re: Adding support for a global src tree serial number) Message-ID: <20020131112549.B1475@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <79909.1012481992@axl.seasidesoftware.co.za> <200201311726.g0VHQ9701193@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201311726.g0VHQ9701193@vashon.polstra.com>; from arch@freebsd.org on Thu, Jan 31, 2002 at 09:26:09AM -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 Thu, Jan 31, 2002 at 09:26:09AM -0800, John Polstra wrote: > PS - I changed the from address because I don't want to be on the > cc of a long thread. Don't add me back. I'll read this stuff in > freebsd-arch. And don't lecture me about procmail, because I know > exactly what I'm doing. :-) I'm going to add this to my .sig! BTW, did you hear anything back about the Sparc denotation? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 11:54:58 2002 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 EC35A37B400 for ; Thu, 31 Jan 2002 11:54:54 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id EF1915341; Thu, 31 Jan 2002 20:54: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: Jos Backus Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131191754.GB75898@lizzy.bugworks.com> From: Dag-Erling Smorgrav Date: 31 Jan 2002 20:54:45 +0100 In-Reply-To: <20020131191754.GB75898@lizzy.bugworks.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 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 Jos Backus writes: > On Thu, Jan 31, 2002 at 07:22:36PM +0100, Dag-Erling Smorgrav wrote: > > Yes, I totally agree that we should switch to Perforce. > Subversion? FMH! DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 12:44:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from xerxes.courtesan.com (courtesan.com [206.168.103.86]) by hub.freebsd.org (Postfix) with ESMTP id 8D6BE37B405 for ; Thu, 31 Jan 2002 12:44:40 -0800 (PST) Received: from xerxes.courtesan.com (IDENT:millert@localhost.courtesan.com [127.0.0.1]) by xerxes.courtesan.com (8.12.2/8.12.1) with ESMTP id g0VKhrDx004889; Thu, 31 Jan 2002 13:43:54 -0700 (MST) Message-Id: <200201312043.g0VKhrDx004889@xerxes.courtesan.com> To: "Perry E. Metzger" Cc: "M. Warner Losh" , wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question In-reply-to: Your message of "31 Jan 2002 11:43:41 EST." <87d6zq31z6.fsf@snark.piermont.com> References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> <87d6zq31z6.fsf@snark.piermont.com> Date: Thu, 31 Jan 2002 13:43:53 -0700 From: "Todd C. Miller" Sender: owner-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 <87d6zq31z6.fsf@snark.piermont.com> so spake "Perry E. Metzger" (perry): > If you do it by hand, we'll get source diffs by accident. If we build > a quick set of scripts to do it, since we'll all be using the same > scripts, we'll end up with fewer diffs. My inclination is to do the simple stuff programatically and do the more complicated things by hand. A simple, dumb, ed script such as the following is capable of changing the majority of things. It doesn't attempt to deal with multi-line prototypes nor does it try to convert prototypes that contain parens. These remaining things can then be converted by hand. Yes, you could hack up a perl script to try and do everything but would you really trust it? I wouldn't. My script can be called thusly: find bin -type f | xargs convert.ed #!/bin/sh for f in $@; do /bin/ed - $f <<'EOF' %s/[ ]*__P[ ]*((\([^()]*\)))/(\1)/g w q EOF done To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 12:50:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by hub.freebsd.org (Postfix) with ESMTP id 5E34937B404 for ; Thu, 31 Jan 2002 12:50:33 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 88DF1D97CA; Thu, 31 Jan 2002 15:50:32 -0500 (EST) From: "Perry E. Metzger" To: "Todd C. Miller" Cc: "M. Warner Losh" , wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> <87d6zq31z6.fsf@snark.piermont.com> <200201312043.g0VKhrDx004889@xerxes.courtesan.com> Date: 31 Jan 2002 15:50:32 -0500 In-Reply-To: <200201312043.g0VKhrDx004889@xerxes.courtesan.com> Message-ID: <87elk6z1lz.fsf@snark.piermont.com> 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 "Todd C. Miller" writes: > Yes, you could hack up a perl script to try and do everything but > would you really trust it? I wouldn't. That's why you cvs diff before committing -- but it would be nice if the editing itself was (generally) automated so we don't have to worry too much. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 13: 7:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from draco.over-yonder.net (draco.over-yonder.net [198.78.58.61]) by hub.freebsd.org (Postfix) with ESMTP id C5D8037B416 for ; Thu, 31 Jan 2002 13:07:21 -0800 (PST) Received: by draco.over-yonder.net (Postfix, from userid 100) id B327AFC4; Thu, 31 Jan 2002 15:07:20 -0600 (CST) Date: Thu, 31 Jan 2002 15:07:20 -0600 From: "Matthew D. Fuller" To: Josef Karthauser Cc: Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131150720.A33201@over-yonder.net> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5-fullermd.1i In-Reply-To: <20020131184230.D84715@genius.tao.org.uk>; from joe@tao.org.uk on Thu, Jan 31, 2002 at 06:42:30PM +0000 X-Editor: vi X-OS: FreeBSD Sender: owner-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, Jan 31, 2002 at 06:42:30PM +0000 I heard the voice of Josef Karthauser, and lo! it spake thus: > > The problem is where to put the serial number, and how to distribute it. > It needs to be maintained in a ,v file for cvs to be able to check it > out. That adds additional complexity. Note also the additional trouble of underhandedly hand-crafting a ,v-alike file will break checking out a revision other than the absolute latest on the branch, since you'll end up with either no serial, or still the latest serial, depending on how the file is crafted. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 13:10:38 2002 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 6536237B416 for ; Thu, 31 Jan 2002 13:10:28 -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 OAA27392; Thu, 31 Jan 2002 14:10:20 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0VLAH216943; Thu, 31 Jan 2002 14:10: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: <15449.45750.572076.480900@caddis.yogotech.com> Date: Thu, 31 Jan 2002 14:10:14 -0700 To: "Matthew D. Fuller" Cc: Josef Karthauser , Nate Williams , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: <20020131150720.A33201@over-yonder.net> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> <20020131150720.A33201@over-yonder.net> X-Mailer: VM 6.96 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 > > The problem is where to put the serial number, and how to distribute it. > > It needs to be maintained in a ,v file for cvs to be able to check it > > out. That adds additional complexity. > > Note also the additional trouble of underhandedly hand-crafting a > ,v-alike file will break checking out a revision other than the absolute > latest on the branch, since you'll end up with either no serial, or still > the latest serial, depending on how the file is crafted. In general, that would only be a problem with folks that have the CVS tree who have updated their CVS tree but have not updated their /usr/src tree. In general, I don't consider this to be a bad thing, since otherwise any solution you had would have to keep a complete running history of all the revisions, which is IMO unacceptable. (JDP has also stated his dislike for such a file.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 13:18:38 2002 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 244FB37B402 for ; Thu, 31 Jan 2002 13:18:31 -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 g0VLIBo37606; Thu, 31 Jan 2002 14:18:11 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0VLI8x34175; Thu, 31 Jan 2002 14:18:08 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 14:17:50 -0700 (MST) Message-Id: <20020131.141750.69220611.imp@village.org> To: perry@wasabisystems.com Cc: wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.org, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, Todd.Miller@courtesan.com, deraadt@cvs.openbsd.org Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <87d6zq31z6.fsf@snark.piermont.com> References: <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> <87d6zq31z6.fsf@snark.piermont.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <87d6zq31z6.fsf@snark.piermont.com> "Perry E. Metzger" writes: : It might be bad for you to do this by hand. : : If you do it by hand, we'll get source diffs by accident. If we build : a quick set of scripts to do it, since we'll all be using the same : scripts, we'll end up with fewer diffs. If you give me a script, I'll run it, otherwise I'm doing it the way I'm doing it. I couldn't write a good RE that spanned multiple lines, but did have an emacs macro that worked well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 13:30:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from draco.over-yonder.net (draco.over-yonder.net [198.78.58.61]) by hub.freebsd.org (Postfix) with ESMTP id 00E2037B41D for ; Thu, 31 Jan 2002 13:30:22 -0800 (PST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 9CB8CFC4; Thu, 31 Jan 2002 15:30:21 -0600 (CST) Date: Thu, 31 Jan 2002 15:30:21 -0600 From: "Matthew D. Fuller" To: Nate Williams Cc: Josef Karthauser , Sheldon Hearn , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020131153021.B36665@over-yonder.net> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> <20020131150720.A33201@over-yonder.net> <15449.45750.572076.480900@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5-fullermd.1i In-Reply-To: <15449.45750.572076.480900@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 31, 2002 at 02:10:14PM -0700 X-Editor: vi X-OS: FreeBSD Sender: owner-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, Jan 31, 2002 at 02:10:14PM -0700 I heard the voice of Nate Williams, and lo! it spake thus: > > In general, that would only be a problem with folks that have the CVS > tree who have updated their CVS tree but have not updated their /usr/src > tree. Actually, I was thinking more of: "I did a make world and the resulting system {wasn't as stable,}, so I checked out with {CVS,CVSup} a tree from 2 weeks ago and built it, and now I have {no serial number,the latest serial number}." > In general, I don't consider this to be a bad thing, since otherwise any > solution you had would have to keep a complete running history of all > the revisions, which is IMO unacceptable. (JDP has also stated his > dislike for such a file.) Ooh, I dislike such a file rather intensely myself. Just the thought of watching a CVSup copy down a file with a few hundred revisions every time I run it is scary, to say nothing of the space it would take up after a few years. I don't have a solution for this, only the problem. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 13:38:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from web20408.mail.yahoo.com (web20408.mail.yahoo.com [216.136.226.127]) by hub.freebsd.org (Postfix) with SMTP id 01D6B37B417 for ; Thu, 31 Jan 2002 13:38:21 -0800 (PST) Message-ID: <20020131213819.96686.qmail@web20408.mail.yahoo.com> Received: from [24.60.36.208] by web20408.mail.yahoo.com via HTTP; Thu, 31 Jan 2002 13:38:19 PST Date: Thu, 31 Jan 2002 13:38:19 -0800 (PST) From: Jules Gilbert Reply-To: jg@medg.lcs.mit.edu Subject: increasing the available address space with FreeBSD To: grog@lemis.com Cc: pg@eth1.com, freebsd-arch@freebsd.org, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.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 Dear Greg: Hi. I need to run large address space jobs using FreeBSD 4.3 I have already upp'ed the available space to about 1.5GB (6 * 256MB). But that was not enough and now I would like to go to at least 2GB or perhaps!, 2.5GB. At present time we have the following params in the kernel config; MAXDSIZ="(1024*1024*6*256)" DFLDSIZ="(1024*1024*6*256)" Also kernel has been slimmed down to exclude any and all unnecessary devices and parameters we are not using. Can you help me understand what I need to do. I am an experienced programmer and this is quite important to me. I hope you feel appreciated. Many people in the FreeBSD community value your service. My application does not require any graphics or X support. All I need to do is issue many large mallocs'. (Seems so simple, doesn't it.) Sincerely, Jules Gilbert ===== Jules Gilbert ------------- Please send all e-mail to julesgilbert2000@yahoo.com as I am trying to knock out the spam I've been getting, and Yahoo has better automatic filtering tools than I do. __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 13:44:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id D88F437B404 for ; Thu, 31 Jan 2002 13:44:26 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020131214421.CMSE7443.rwcrmhc54.attbi.com@peter3.wemm.org> for ; Thu, 31 Jan 2002 21:44:21 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0VLiLs56775 for ; Thu, 31 Jan 2002 13:44:21 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 384483809 for ; Thu, 31 Jan 2002 13:44:21 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: FreeBSD-arch Subject: Re: Adding support for a global src tree serial number In-Reply-To: <200201311726.g0VHQ9701193@vashon.polstra.com> Content-Transfer-Encoding: 8bit Date: Thu, 31 Jan 2002 13:44:21 -0800 From: Peter Wemm Message-Id: <20020131214421.384483809@overcee.wemm.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 John Polstra wrote: > In article <79909.1012481992@axl.seasidesoftware.co.za>, > Sheldon Hearn wrote: > > > > I didn't realize that cvsup mirrors might offer me a src/bin that's > > newer than the src/sbin that it offers me (for example). > > Yes, that's what would happen, except most likely in reverse. CVSup > processes the tree in alphabetical order. > > But I object to this idea for a different reason. Every day a large > number of commits are made to the src tree. You are proposing that > every one of those commits would add a delta to the serial number > file. That file would soon have tens of thousands of deltas. That > makes it quite inefficient for both cvs and CVSup. This idea simply > doesn't scale to the long-term. I am in complete agreement. We aren't going to get a meaningful result with the system as proposed. CVS simply doesn't support atomic changes. cvsup doesn't particularly help either since it browses the cvs tree at leisure and does no locking etc. While it would be damn nice to have (nobody is denying that), we just simply do not have the means to do it in a reliable meaningful way. If you want atomic change numbers then we have to look elsewhere at other SCM's and distribution mechanisms. The atomic change part is well solved by perforce (www.perforce.com), maybe subversion one day (subversion.tigris.org), and probably others. But these dont solve the distribution problem. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 14: 4:52 2002 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 2DDA537B402 for ; Thu, 31 Jan 2002 14:04:44 -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 g0VM4Xi51296; Thu, 31 Jan 2002 17:04:34 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <15449.45750.572076.480900@caddis.yogotech.com> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> <20020131150720.A33201@over-yonder.net> <15449.45750.572076.480900@caddis.yogotech.com> Date: Thu, 31 Jan 2002 17:04:32 -0500 To: nate@yogotech.com (Nate Williams), "Matthew D. Fuller" From: Garance A Drosihn Subject: Re: Adding support for a global src tree serial number Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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 2:10 PM -0700 1/31/02, Nate Williams wrote: > > > The problem is where to put the serial number, and how to > > > distribute it. It needs to be maintained in a ,v file for cvs > > > to be able to check it out. That adds additional complexity. > > > > Note also the additional trouble of underhandedly hand-crafting a > > ,v-alike file will break checking out a revision other than the > > absolute latest on the branch, since you'll end up with either no > > serial, or still the latest serial, depending on how the file is > > crafted. > >In general, that would only be a problem with folks that have the >CVS tree who have updated their CVS tree but have not updated their >/usr/src tree. Would it work for me? I have a local cvs tree which I update using cvsup. It exists in a separate partition, /usr/cvs The machine is a dual-boot machine (-stable and -current). Both systems mount the same /usr/cvs partition, and use it to update their respective /usr/src's. How does each /usr/src get the correct serial-number, if the serial-number file is not in cvs? I use this same tactic on both my machines (at work and at home), so I can track multiple OS images and yet only have to contact a cvsup server once per machine. Sometimes those multiple images are not separate branches, but just separate time-stamps in the same branch. >In general, I don't consider this to be a bad thing, since otherwise any >solution you had would have to keep a complete running history of all >the revisions, which is IMO unacceptable. (JDP has also stated his >dislike for such a file.) I agree that having the serial-number file in CVS is distasteful, due to how often it will be changed, but it seems to me that is the only way to have things work right for people who are using a local cvs repository. /usr/src has to end up with the right serial number for that /usr/src, and not the most recent one stuffed into the cvs repository. However, I am not a cvs wizard, so maybe it is possible to track the serial numbers without having a serial-number file under cvs. I don't know, but I wanted to describe how I use cvsup so people could consider how the serial-number would need to work in my situation. -- 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 Jan 31 14: 8:12 2002 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 EDED937B400 for ; Thu, 31 Jan 2002 14:08:03 -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 PAA29690; Thu, 31 Jan 2002 15:08:01 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0VM7tj17305; Thu, 31 Jan 2002 15:07:55 -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: <15449.49211.508201.314013@caddis.yogotech.com> Date: Thu, 31 Jan 2002 15:07:55 -0700 To: Garance A Drosihn Cc: nate@yogotech.com (Nate Williams), "Matthew D. Fuller" , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> <20020131150720.A33201@over-yonder.net> <15449.45750.572076.480900@caddis.yogotech.com> X-Mailer: VM 6.96 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 > > > > The problem is where to put the serial number, and how to > > > > distribute it. It needs to be maintained in a ,v file for cvs > > > > to be able to check it out. That adds additional complexity. > > > > > > Note also the additional trouble of underhandedly hand-crafting a > > > ,v-alike file will break checking out a revision other than the > > > absolute latest on the branch, since you'll end up with either no > > > serial, or still the latest serial, depending on how the file is > > > crafted. > > > >In general, that would only be a problem with folks that have the > >CVS tree who have updated their CVS tree but have not updated their > >/usr/src tree. > > Would it work for me? I have a local cvs tree which I update using > cvsup. It exists in a separate partition, /usr/cvs My proposal would work for you, since the 'file' would have at least one revision in it for every branch. > The machine is a dual-boot machine (-stable and -current). Both systems > mount the same /usr/cvs partition, and use it to update their respective > /usr/src's. How does each /usr/src get the correct serial-number, if the > serial-number file is not in cvs? That's my point. I think it *has* to be in CVS. > I agree that having the serial-number file in CVS is distasteful, due to > how often it will be changed, but it seems to me that is the only way to > have things work right for people who are using a local cvs > repository. We're in violent agreement here. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 14:29: 0 2002 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 9542637B400 for ; Thu, 31 Jan 2002 14:28:52 -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 g0VMROi118974; Thu, 31 Jan 2002 17:27:24 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200201312043.g0VKhrDx004889@xerxes.courtesan.com> References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> <87d6zq31z6.fsf@snark.piermont.com> <200201312043.g0VKhrDx004889@xerxes.courtesan.com> Date: Thu, 31 Jan 2002 17:27:22 -0500 To: "Todd C. Miller" , "Perry E. Metzger" From: Garance A Drosihn Subject: Re: __P macro question Cc: "M. Warner Losh" , wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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:43 PM -0700 1/31/02, Todd C. Miller wrote: >In message <87d6zq31z6.fsf@snark.piermont.com> > so spake "Perry E. Metzger" (perry): > >> If you do it by hand, we'll get source diffs by accident. If we build >> a quick set of scripts to do it, since we'll all be using the same >> scripts, we'll end up with fewer diffs. > >My inclination is to do the simple stuff programatically and do the >more complicated things by hand. A simple, dumb, ed script such >as the following is capable of changing the majority of things. It >doesn't attempt to deal with multi-line prototypes nor does it try >to convert prototypes that contain parens. These remaining things >can then be converted by hand. I believe Warner's plan for 'bin' is to both get rid of __P()'s, and to change routine declarations to be ANSI-style. The __P()'s are pretty easy to do with a script, but I think the declarations pretty much have to be done by hand. I may be using the wrong term there by saying 'declarations'... I mean the parameters as described at the start of the actual code for the routine. I did this to lpr a few months ago, and came across things like: static void scan_out(pp, scfd, scsp, dlm) struct printer *pp; int scfd, dlm; char *scsp; { Turning into: static void scan_out(struct printer *pp, int scfd, char *scsp, int dlm) { Ie, the parameters are specified in a different order for the parameter list than they are when listing their types. This would be hard to automate with any simple script... I also came across things like a prototype of: static int sendfile __P((struct printer *pp, int type, char *file, int format)); for a procedure declaration of: static int sendfile(pp, type, file, format) struct printer *pp; int type; char *file; char format; { (where the type for 'format' is different in the prototype than it is in the routine). In my case, I checked the end result of all my changes by using 'md5' on the object code, and either attempt to fix the above caused a change for the object code generated under Alpha. So when doing this to lpr, I started out thinking I would write some script to automate the conversion, but in the end I decided to do it all by hand just so I knew exactly what was going on... Note that I'm not doing any of the work for THIS drive to get rid of __P(), so everyone can safely ignore what I'm saying. As long as everyone else is happy with the plan, I have nothing to add. :-) -- 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 Jan 31 14:36:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by hub.freebsd.org (Postfix) with ESMTP id 5E5A337B405 for ; Thu, 31 Jan 2002 14:36:14 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by renown.cnchost.com id RAA00395; Thu, 31 Jan 2002 17:36:12 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200201312236.RAA00395@renown.cnchost.com> To: Jeroen Ruigrok/asmodai Cc: arch@FreeBSD.ORG Subject: A C dialect called GCC C (was Re: __P macro question) In-reply-to: Your message of "Thu, 31 Jan 2002 08:34:30 +0100." <20020131073430.GR22384@daemon.ninth-circle.org> Date: Thu, 31 Jan 2002 14:36:11 -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 > -On [20020130 20:45], Bakul Shah (bakul@bitblocks.com) wrote: > >Similarly, if Terry were to make the changes to the FreeBSD > >kernel to compile it with TenDRA (and make it work) at least > >I would be very grateful to him -- I do think relying so much > >on GCC is a bad idea but I am realistic (and lazy) enough to > >not want to fix that on my own. > > As someone who has been hacking TenDRA for a while now and trying to get > it up-to-date a bit, I can tell you FreeBSD is written in a C dialect > called GCC C. Yeah, I am well aware of it; which is why I raised this issue + the fact this is a much more serious issue than to __P or not to __P! I'd be interested to know what you found from your TenDRA hacking. From what I know, the GCC-isms used are: long long -- this is already in the C9x standard __attribute -- the common use seems to be for better type checking. I think one can live without this. asm() -- this is different for different processors in any case. But I agree some sort of asm support will most likely be needed. Also, the ability to mix C expressions as operands inline -- needed for performance. Already in C9x. typeof -- handy especially in macros but we can live without this with an extra macro arg where the type is passed in. ({...}) -- this is a way to declare local temp vars in an expression. There is no need for this given inline functions (though a bit more verbose) int array[n] -- variable length array. This is in C9x. // comments -- in C9x. I am not sure the following extensions are used in the kernel: alignment -- not sure if specifying alignment is needed in .c files int x = y; -- non constant initializers. Need an _init() section to deal with this. a?:b -- lazy conditional. Handy but can do without vararg macros -- this is in C9x in a slightly different form computed goto -- labels as lvalues. Improves interpreter performance but I doubt this is used in the kernel. global registers cast to unions etc. I am sure I have missed quite a few things but on first glance it seems the work needed to use TenDRA for compiling the kernel will also take it in the direction of C9x compliance, which is a good thing. Until TenDRA comes close to compiling the kernel there is no incentive for people to not use gccisms let alone remove the existing ones. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 14:36:49 2002 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 86AE437B402 for ; Thu, 31 Jan 2002 14:36:41 -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 g0VMaRo37967; Thu, 31 Jan 2002 15:36:27 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0VMaOx34860; Thu, 31 Jan 2002 15:36:24 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 15:36:07 -0700 (MST) Message-Id: <20020131.153607.63055791.imp@village.org> To: drosih@rpi.edu Cc: Todd.Miller@courtesan.com, perry@wasabisystems.com, wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: References: <87d6zq31z6.fsf@snark.piermont.com> <200201312043.g0VKhrDx004889@xerxes.courtesan.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Garance A Drosihn writes: : I also came across things like a prototype of: : static int sendfile __P((struct printer *pp, int type, char *file, : int format)); : : for a procedure declaration of: : static int : sendfile(pp, type, file, format) : struct printer *pp; : int type; : char *file; : char format; : { That's *EXCATLY* why I'm converting the old, but still legal in c89, style to new style. You get warnings that you didn't get before. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 14:37:35 2002 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 13B7737B402 for ; Thu, 31 Jan 2002 14:37: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 g0VMbJi109822; Thu, 31 Jan 2002 17:37:19 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za> References: <79300.1012474898@axl.seasidesoftware.co.za> Date: Thu, 31 Jan 2002 17:37:18 -0500 To: Sheldon Hearn , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Adding support for a global src tree serial number Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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:01 PM +0200 1/31/02, Sheldon Hearn wrote: >Hi folks, > >I'd like to propose the addition of a global src tree serial number >that uniquely identifies an imaginary snapshot of the src tree. > >Essentially, the serial number lives in a file, the name of which is >not important until I have buy-in on the concept. Let's call it >src/SERIAL for now. > >Every time a delta is applied to a branch, the serial number in >src/SERIAL is automatically incremented through a "stealth commit" on >that branch. This ensures that, if the src tree is checked out in its >entirety and left unmodified, this serial number identifies the state >of the entire tree. > >In addition, the serial number will be included in the commonly >requested output of 'uname -a' through modifications ot newvers.sh. I like the idea, although I can see that it might be a little tricky to figure out a good implementation. As to the serial number itself, let me suggest: <4-digit year><1-letter for month>-- eg: 2002A-4.5R-0001 For the first serial number added to branch 4.4-release in Jan 2002. ('A' for Janary, ..., 'C' for December). However, I'm fine with any other serial number scheme that someone comes up with. Mainly I think there should be some indication of time, but not a pure timestamp, and some indication of the branch. I also wouldn't want to end up with a 40-character serial number that is so cleverly encoded that you'd need a program to figure out what it's saying... I decided to make a suggestion for the serial number, because I can't think of a particularly good solution to all the technical issues... :-) -- 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 Jan 31 15:14: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from xerxes.courtesan.com (courtesan.com [206.168.103.86]) by hub.freebsd.org (Postfix) with ESMTP id DC5EC37B405 for ; Thu, 31 Jan 2002 15:14:04 -0800 (PST) Received: from xerxes.courtesan.com (IDENT:millert@localhost.courtesan.com [127.0.0.1]) by xerxes.courtesan.com (8.12.2/8.12.1) with ESMTP id g0VNDLDx021778; Thu, 31 Jan 2002 16:13:21 -0700 (MST) Message-Id: <200201312313.g0VNDLDx021778@xerxes.courtesan.com> To: Garance A Drosihn Cc: "Perry E. Metzger" , "M. Warner Losh" , wes@softweyr.com, tlambert2@mindspring.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question In-reply-to: Your message of "Thu, 31 Jan 2002 17:27:22 EST." References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.org> <87d6zq31z6.fsf@snark.piermont.com> <200201312043.g0VKhrDx004889@xerxes.courtesan.com> Date: Thu, 31 Jan 2002 16:13:21 -0700 From: "Todd C. Miller" Sender: owner-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 so spake Garance A Drosihn (drosih): > I believe Warner's plan for 'bin' is to both get rid of __P()'s, > and to change routine declarations to be ANSI-style. The __P()'s > are pretty easy to do with a script, but I think the declarations > pretty much have to be done by hand. Yes, definately. However, when I talked to Kirk he indicated the the only thing on the table was getting rid of __P. While I think that converting from old to new style function declarations is a good thing I think it makes sense to do that as a separate step. - todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 15:37:34 2002 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 8C78637B402 for ; Thu, 31 Jan 2002 15:37:17 -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 g0VNbGo38257; Thu, 31 Jan 2002 16:37:16 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0VNbEx35211; Thu, 31 Jan 2002 16:37:15 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 16:36:57 -0700 (MST) Message-Id: <20020131.163657.122059617.imp@village.org> To: Todd.Miller@courtesan.com Cc: perry@wasabisystems.com, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <200201312313.g0VNDLDx021778@xerxes.courtesan.com> References: <200201312043.g0VKhrDx004889@xerxes.courtesan.com> <200201312313.g0VNDLDx021778@xerxes.courtesan.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200201312313.g0VNDLDx021778@xerxes.courtesan.com> "Todd C. Miller" writes: : In message : so spake Garance A Drosihn (drosih): : : > I believe Warner's plan for 'bin' is to both get rid of __P()'s, : > and to change routine declarations to be ANSI-style. The __P()'s : > are pretty easy to do with a script, but I think the declarations : > pretty much have to be done by hand. : : Yes, definately. However, when I talked to Kirk he indicated the : the only thing on the table was getting rid of __P. While I think : that converting from old to new style function declarations is a : good thing I think it makes sense to do that as a separate step. Kirk didn't ask me what I was going to do before asking you :-). My plan had all along been to do more than just __P removal. However, after just now completing FreeBSD's src/bin directories, I'd have to agree that for other directories, I'm going to do this in two steps. 1 for __P and the other for protoize. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 15:44:54 2002 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 0F16537B400; Thu, 31 Jan 2002 15:44:50 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16WQvi-000Mao-00; Fri, 01 Feb 2002 01:47:46 +0200 From: Sheldon Hearn To: obrien@FreeBSD.org Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number In-reply-to: Your message of "Thu, 31 Jan 2002 11:22:01 PST." <20020131112201.A1475@dragon.nuxi.com> Date: Fri, 01 Feb 2002 01:47:46 +0200 Message-ID: <86849.1012520866@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, 31 Jan 2002 11:22:01 PST, "David O'Brien" wrote: > On Thu, Jan 31, 2002 at 01:01:38PM +0200, Sheldon Hearn wrote: > > I'd like to propose the addition of a global src tree serial number that > > uniquely identifies an imaginary snapshot of the src tree. > > This really isn't arch related materal. Care to go a step further and tell me what FreeBSD mailing list I should have posted to? :-) 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 Jan 31 16: 9:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 7774437B416 for ; Thu, 31 Jan 2002 16:09:28 -0800 (PST) Received: from pool0167.cvx40-bradley.dialup.earthlink.net ([216.244.42.167] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WRGb-0006uM-00; Thu, 31 Jan 2002 16:09:22 -0800 Message-ID: <3C59DCAA.3121F616@mindspring.com> Date: Thu, 31 Jan 2002 16:09:14 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mats Lofkvist Cc: n@nectar.cc, sheldonh@starjuice.net, arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> <3C5947DC.DB3AD4B2@mindspring.com> <20020131140226.12792.qmail@kairos.algonet.se> 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 Mats Lofkvist wrote: > But, if you knew the exact order of changes, you could start > with a list of all files with versions at the start time and > then check the MD5 for all changes until the end time by > replacing the version of each changed file. This is only > number-of-files * number-of-changes. Perhaps we could use a distributed client, like "seti@home" in order to figure out what MD5 goes with what set of files? 8-) -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 16:30: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 8922737B402 for ; Thu, 31 Jan 2002 16:30:03 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id C4D8C314; Fri, 1 Feb 2002 00:30:00 +0000 (GMT) Date: Fri, 1 Feb 2002 00:30:00 +0000 From: Josef Karthauser To: Nate Williams Cc: Garance A Drosihn , "Matthew D. Fuller" , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number Message-ID: <20020201003000.B87231@genius.tao.org.uk> References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <20020131183321.GA59544@gattaca.yadt.co.uk> <20020131184230.D84715@genius.tao.org.uk> <20020131150720.A33201@over-yonder.net> <15449.45750.572076.480900@caddis.yogotech.com> <15449.49211.508201.314013@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15449.49211.508201.314013@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 31, 2002 at 03:07:55PM -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 --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2002 at 03:07:55PM -0700, Nate Williams wrote: > > > > Note also the additional trouble of underhandedly hand-crafting a > > > > ,v-alike file will break checking out a revision other than the > > > > absolute latest on the branch, since you'll end up with either no > > > > serial, or still the latest serial, depending on how the file is > > > > crafted. > > > > > >In general, that would only be a problem with folks that have the > > >CVS tree who have updated their CVS tree but have not updated their > > >/usr/src tree. > >=20 > > Would it work for me? I have a local cvs tree which I update using > > cvsup. It exists in a separate partition, /usr/cvs >=20 > My proposal would work for you, since the 'file' would have at least one > revision in it for every branch. My proposal would also work because every file that contributes to your kernel source has a revision tag. It follows that the most recent tag date across all of those files describes the most recent commit in the repository that lead that that kernel. It's probably sufficient just to look at src/sys/ to determine a date that's close enough to support from. It requires no CVSROOT or cvsup or cvs hackery and requires just a short amount of extra time (1.5 minutes on my -current laptop) which is nothing compared to the length of a normal build with all the modules and everything. Let's have it switch-off-able in make.conf, and advertised in the kernel version string. Joe --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxZ4YgACgkQXVIcjOaxUBZzVQCghYysaX0D/5F6PHohJt9IVwhQ CHoAoMSn4M7r9V+mrVRFT91eQ/arsByr =cyjg -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 16:38:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 3D23F37B416 for ; Thu, 31 Jan 2002 16:38:18 -0800 (PST) Received: from pool0167.cvx40-bradley.dialup.earthlink.net ([216.244.42.167] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WRi6-0002XU-00; Thu, 31 Jan 2002 16:37:47 -0800 Message-ID: <3C59E354.E7DAD502@mindspring.com> Date: Thu, 31 Jan 2002 16:37:40 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: wes@softweyr.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, perry@wasabisystems.com, Todd.Miller@courtesan.com, deraadt@cvs.openbsd.org Subject: Re: __P macro question References: <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com> <3C58FBEC.746257BB@softweyr.com> <20020131.085938.18394797.imp@village.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 "M. Warner Losh" wrote: > I'm almost done with bin. I have a emacs macro to help me with __P() > and have been doing the prototyping by hand, but it dawned on my that > protoize may be the right tool here, so I'll be playing with that when > I start up again. /bin/sh is the only thing I have left. Patches to > be posted today or tomorrow. If all you care about is "\ __P(.*);" -> ".*;", sed is your friend. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 16:39:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 6B3B237B405; Thu, 31 Jan 2002 16:39:16 -0800 (PST) Received: from pool0167.cvx40-bradley.dialup.earthlink.net ([216.244.42.167] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WRjW-0004Tu-00; Thu, 31 Jan 2002 16:39:14 -0800 Message-ID: <3C59E3AD.B43D374F@mindspring.com> Date: Thu, 31 Jan 2002 16:39:09 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: ru@FreeBSD.ORG, sheldonh@starjuice.net, arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131140403.A69232@sunbay.com> <20020131.091003.108028797.imp@village.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 "M. Warner Losh" wrote: > : This scheme won't work because the state of the tree can be modified > : by CVS meisters performing direct operations on a repository. See > : how stealthy the latest GCC import gone. > > Also right now two committers can be committing to different parts of > the tree at the same time, so A might get his src commit in first, but > get the second serial because B races his commit in and wins the race > for the global serial number. Worse. If you have explicit file lists spanning two directories, you can have two overlapping commits occuring at the same time in inverse directions, resulting in conflicts for both committers. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 16:42:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 5FA8637B416 for ; Thu, 31 Jan 2002 16:42:13 -0800 (PST) Received: from pool0167.cvx40-bradley.dialup.earthlink.net ([216.244.42.167] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WRmB-0000EY-00; Thu, 31 Jan 2002 16:42:00 -0800 Message-ID: <3C59E452.FEC81CB9@mindspring.com> Date: Thu, 31 Jan 2002 16:41:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: sheldonh@starjuice.net, molter@tin.it, arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number References: <20020131112850.GB28361@cobweb.example.org> <79603.1012479536@axl.seasidesoftware.co.za> <20020131.091150.67419427.imp@village.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 [ ... ] 1) Create a file in the repository at the top level, "SERIAL" 2) Modify CVS commit to "touch" it each time a file is changed, by opening it directly for write, and closing it (use a daemon to do it, if you are paranoid) 3) Just use the date stamp on the file as the serial -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 16:53:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id C00E137B402 for ; Thu, 31 Jan 2002 16:53:09 -0800 (PST) Received: from pool0167.cvx40-bradley.dialup.earthlink.net ([216.244.42.167] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WRwl-0006Tw-00; Thu, 31 Jan 2002 16:52:56 -0800 Message-ID: <3C59E6E2.BFC3836A@mindspring.com> Date: Thu, 31 Jan 2002 16:52:50 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Sheldon Hearn , Marco Molteni , arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Basically you are talking about an extension to the commit logging > process. > > it would be good if the file also listed all files changed in that commit. The problem is a little larger. o What if I'm on another branch? o What if my source code was checked out last Tuesday, and I've continued to CVSup? o What if I told CVS to check out by date, to ensure I got the code from last Tuesday? The last one is the kicker, since it's what people are going to use to reproduce problems, since really, what they want is a "check out by serial number" so they can see the problems someone is having with a given serial number, and fix them. In other words, the serial number can't just be HEAD-invariant per branch. Nate's approach of raw reading and writing the RCS file is the only workable one, I think, and there are still race windows for a partially eddited file obtained via CVSup. The only way around this is a two stage commit replacement of the file, and that leaves a sliver of a window where there is a "file.old" and a "file.new", without a "file" linked to one or the other, unless a hard link is allowed to replace a file, and CVSup will probably barf on it not being there, so it would have to be modified to back off and retry. This is basically the reason I dsuggested a daemon, in my previous posting. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 17:15:31 2002 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 3484037B41A for ; Thu, 31 Jan 2002 17:15:28 -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 SAA07222; Thu, 31 Jan 2002 18:15:10 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g111F6i19299; Thu, 31 Jan 2002 18:15:06 -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: <15449.60441.991470.801399@caddis.yogotech.com> Date: Thu, 31 Jan 2002 18:15:05 -0700 To: Terry Lambert Cc: "M. Warner Losh" , sheldonh@starjuice.net, molter@tin.it, arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number In-Reply-To: <3C59E452.FEC81CB9@mindspring.com> References: <20020131112850.GB28361@cobweb.example.org> <79603.1012479536@axl.seasidesoftware.co.za> <20020131.091150.67419427.imp@village.org> <3C59E452.FEC81CB9@mindspring.com> X-Mailer: VM 6.96 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 > [ ... ] > > 1) Create a file in the repository at the top level, "SERIAL" > 2) Modify CVS commit to "touch" it each time a file is > changed, by opening it directly for write, and closing it > (use a daemon to do it, if you are paranoid) > 3) Just use the date stamp on the file as the serial What about multiple branches? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 18:33: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 0F8D937B404 for ; Thu, 31 Jan 2002 18:33:01 -0800 (PST) Received: from pool0359.cvx40-bradley.dialup.earthlink.net ([216.244.43.104] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WTVS-0000O6-00; Thu, 31 Jan 2002 18:32:51 -0800 Message-ID: <3C59F4EB.F0B04D5A@mindspring.com> Date: Thu, 31 Jan 2002 17:52:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Josef Karthauser , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Adding support for a global src tree serial number References: <3C5944A4.4927F812@mindspring.com> <80628.1012484102@axl.seasidesoftware.co.za> <15449.30438.698921.182380@caddis.yogotech.com> <20020131173702.J77899@genius.tao.org.uk> <15449.33154.45261.703514@caddis.yogotech.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 Nate Williams wrote: > > The easiest solution is the one that I proposed in the PR, which is to > > use the effective date of the latest date in the $FreeBSD$ files. > > Won't work. > > > Of course this means going through each source file, but that's only > > time. > > Time is a precious commodity, especially when you talk the entire tree. > Plus, each user may have a different subset of the tree (some wouldn't > have kerberos, some wouldn't have doc, some wouldn't have release, > etc...) > > No standard. Whatever it is has to work on a checked out tree. The approach described will "work" to get a date that can then be used to check out a duplicate tree, but with the caveat that that you can't have a CVSup going at the same time, and you can't have any local work, and the tree must have been checked out clean, and there's an unavoidable latency window caused by the time for checkout. Getting a serial number isn't the goal; Nate's points are valid: the serial number has to be able to be used for something. If you just want it for releases, then you could MD5 the ISOs: not useful. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 18:33:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 293D537B404 for ; Thu, 31 Jan 2002 18:33:21 -0800 (PST) Received: from pool0359.cvx40-bradley.dialup.earthlink.net ([216.244.43.104] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WTVZ-0000Vq-00; Thu, 31 Jan 2002 18:32:57 -0800 Message-ID: <3C59FAFA.1EE9B153@mindspring.com> Date: Thu, 31 Jan 2002 18:18:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: drosih@rpi.edu, Todd.Miller@courtesan.com, perry@wasabisystems.com, wes@softweyr.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question References: <87d6zq31z6.fsf@snark.piermont.com> <200201312043.g0VKhrDx004889@xerxes.courtesan.com> <20020131.153607.63055791.imp@village.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 "M. Warner Losh" wrote: > : static int sendfile __P((struct printer *pp, int type, char *file, > : int format)); > : > : for a procedure declaration of: > : static int > : sendfile(pp, type, file, format) > : struct printer *pp; > : int type; > : char *file; > : char format; > : { > > That's *EXCATLY* why I'm converting the old, but still legal in c89, > style to new style. You get warnings that you didn't get before. The compiler is broken, if it accepts the second when the first prototype is in scope. It's a broken compiler, period. Conversion doesn't fix the compiler brokeness. I thought you were just getting rid of __P()? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 18:36:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from web14007.mail.yahoo.com (web14007.mail.yahoo.com [216.136.175.123]) by hub.freebsd.org (Postfix) with SMTP id 95E2C37B402 for ; Thu, 31 Jan 2002 18:36:25 -0800 (PST) Message-ID: <20020201023625.38173.qmail@web14007.mail.yahoo.com> Received: from [216.103.213.142] by web14007.mail.yahoo.com via HTTP; Thu, 31 Jan 2002 18:36:25 PST Date: Thu, 31 Jan 2002 18:36:25 -0800 (PST) From: k Macy Subject: Re: KSE milestone 3 reached. To: arch@freebsd.org In-Reply-To: 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 Do you really want to get rid of procfs in light of the fact that other platforms that have kernel-visible threads use it (Digital UNIX, Solaris, etc.)? See sol-thread.c for something resembling the approach that may end up being taken. Procfs is used for examining lwps and the thread's library interfaces are used to examine the user-level threads. The ptrace interface seems fundamentally unamenable to, or at least very clumsy at handling multiple threads of control. I'm very uncomfortable with the notion that ptrace will work because it "has to." -Kip > > As far as ptrace(2) is concerned, I think I want all > threads to be > suspended; ptrace(2) doesn't really support the > concept of threads. > Our current version of gdb(1) doesn't support > threads either (AFAIK), > and I don't know if (or how) newer versions of > gdb(1) do; we'll cross > that bridge when we get there. > > > I have not completed this work yet.. > > but am wondering if you have any violent arguments > about what I'm doing.. > > Not really. It just has to work *somehow*, and I > don't really have > any opinion on precisely how. The one request i > have is that > debugging single-threaded processes should work the > way it used to > (i.e. ptrace(2) should behave the same with > single-threaded processes > under KSE as it did pre-KSE) > > 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 > > __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 18:40:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 2A25D37B404 for ; Thu, 31 Jan 2002 18:40:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020201024011.OZND10199.rwcrmhc53.attbi.com@InterJet.elischer.org> for ; Fri, 1 Feb 2002 02:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA64109 for ; Thu, 31 Jan 2002 18:39:23 -0800 (PST) Date: Thu, 31 Jan 2002 18:39:23 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: KSE and SIGNALS (How to feel ill in 30 seconds) 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 Well, we have no real design yet for handling signals in a multi-threaded process. In the current statem the signals would be handled by whatever thread is next returned to by the system, or in fact if it is an upcall, it would be handled on the UTS stack if that was next. (In the current incarnation, all syscalls return with an upcall so quite a few signals would be handled on the UTS stack. In other words whenever the next return to user space is made after the signal is posted, the signal will be acted upon. It is likely that we want to do something a little more consitent than this. Some possibilities: * Leave it as it is.. The signals are done on whatever thread is next, even if it is an upcall. * A special upcall location is assigned for them. The upcall is scheduled instead of whatever the next return to userland would be (which is delayed). * They are returned only on upcalls (choosing the next one up) (upcalls can be done at almost any time that there is not already an upcall in progress). * They are returned only on a particular upcall stack (but it may not be active for a while, maybe we can force it to happen. * They are retunred only on a specified user thread, (but there is nothing to say that the UTS will schedule that thread any time soon. * A separate signal stack is provided. Not an upcall, just dedicated. In addition to this is the complication that ptrace is bound up in signals as well. I'm slowely reworking ptrace so that you can specify a thread but first I have to break it away from using signals to pass it's state because signals are per-process and not per-thread.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 18:53:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from web14007.mail.yahoo.com (web14007.mail.yahoo.com [216.136.175.123]) by hub.freebsd.org (Postfix) with SMTP id 50C2B37B419 for ; Thu, 31 Jan 2002 18:53:18 -0800 (PST) Message-ID: <20020201025318.41243.qmail@web14007.mail.yahoo.com> Received: from [216.103.213.142] by web14007.mail.yahoo.com via HTTP; Thu, 31 Jan 2002 18:53:18 PST Date: Thu, 31 Jan 2002 18:53:18 -0800 (PST) From: k Macy Subject: Re: KSE milestone 3 reached. To: obrien@FreeBSD.ORG, arch@freebsd.org In-Reply-To: <20020129120723.A81682@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Apparently my attempts to trick Kip Macy into > taking over gdb > > maintainership have yet to ripen. :) I'm still here. I misinterpreted your not responding to my questions about GNU paperwork. Anyway, I will have an updated version of freebsd-uthread.c this weekend that has additional fixes for a detach and resume bug that I hit. At some point I'd also like to start looking at Greg Lehey's bug (1849- shared libraries) as I hit it just recently myself, so it would appear that the move to ELF hasn't done anything for that, and stepping through a threaded processes that has queued signals can have it ending up off in la-la land (99% cpu usage - noninterruptible). As I alluded to a few minutes ago, we really need to come up with extensions to the ptrace interface before we even think about taking procfs out. > > I thought we also had roped Mark Peek into that job. > :-) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the > message > > __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 19: 6:36 2002 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 9359737B419 for ; Thu, 31 Jan 2002 19:06:32 -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 g1136Bo39098; Thu, 31 Jan 2002 20:06:12 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g11367x36254; Thu, 31 Jan 2002 20:06:08 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 20:05:49 -0700 (MST) Message-Id: <20020131.200549.85420016.imp@village.org> To: tlambert2@mindspring.com Cc: drosih@rpi.edu, Todd.Miller@courtesan.com, perry@wasabisystems.com, wes@softweyr.com, asmodai@wxs.nl, mckusick@mckusick.com, arch@FreeBSD.ORG, peter@wemm.org, phk@critter.freebsd.dk, deatley@apple.com, jkh@winston.freebsd.org, deraadt@cvs.openbsd.org Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <3C59FAFA.1EE9B153@mindspring.com> References: <20020131.153607.63055791.imp@village.org> <3C59FAFA.1EE9B153@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <3C59FAFA.1EE9B153@mindspring.com> Terry Lambert writes: : "M. Warner Losh" wrote: : > : static int sendfile __P((struct printer *pp, int type, char *file, : > : int format)); : > : : > : for a procedure declaration of: : > : static int : > : sendfile(pp, type, file, format) : > : struct printer *pp; : > : int type; : > : char *file; : > : char format; : > : { : > : > That's *EXCATLY* why I'm converting the old, but still legal in c89, : > style to new style. You get warnings that you didn't get before. : : The compiler is broken, if it accepts the second when the : first prototype is in scope. : : It's a broken compiler, period. : : Conversion doesn't fix the compiler brokeness. Fine. Gcc is broken. I found at least one case of it in the tree already. :-) That's because char is promoted to int when "old style" are used, and not when new style are used. At least that's the only explaination I can think of and I don't care enough to go find the verbage from the standard that says this. That's one of the *@#(%&#^% subtle differences between K&R and ANSI that bite you when you least expect it. int foo9(int a); int foo9(a) char a; { } doesn't produce an error but: int foo9(int a); int foo9(char a) { } does. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 19: 8:40 2002 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 7219C37B404 for ; Thu, 31 Jan 2002 19:08:37 -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 g1138Zi66912; Thu, 31 Jan 2002 22:08:35 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C59FAFA.1EE9B153@mindspring.com> References: <87d6zq31z6.fsf@snark.piermont.com> <200201312043.g0VKhrDx004889@xerxes.courtesan.com> <20020131.153607.63055791.imp@village.org> <3C59FAFA.1EE9B153@mindspring.com> Date: Thu, 31 Jan 2002 22:08:34 -0500 To: Terry Lambert From: Garance A Drosihn Subject: Re: __P macro question Cc: arch@FreeBSD.ORG, Todd.Miller@courtesan.com, perry@wasabisystems.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 6:18 PM -0800 1/31/02, Terry Lambert wrote: > > Garance wrote: > > : static int sendfile __P((struct printer *pp, int type, char *file, >> : int format)); >> : >> : for a procedure declaration of: >> : static int >> : sendfile(pp, type, file, format) >> : struct printer *pp; >> : int type; >> : char *file; >> : char format; > > : { > > >The compiler is broken, if it accepts the second when the >first prototype is in scope. The gcc compiler is a little funny about this. It will say nothing about mismatch of 'int' vs 'char' like the above, but it will warn if you change it so the mismatch is something like 'int' vs 'float'. And it will warn about 'int' vs 'char' if you change the routine declaration to use ANSI-style parameters instead of K&R style. As far as I know, the code produced in the non-warning case will work correctly, but personally I would prefer to get the warning for any mismatch like this... -- 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 Jan 31 19:10: 6 2002 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 2C29A37B416 for ; Thu, 31 Jan 2002 19:10:02 -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 g113A1o39128 for ; Thu, 31 Jan 2002 20:10:01 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g113A0x36278 for ; Thu, 31 Jan 2002 20:10:00 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 31 Jan 2002 20:09:42 -0700 (MST) Message-Id: <20020131.200942.41874592.imp@village.org> To: arch@freebsd.org Subject: Bin diffs From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG OK. Here's my first round of diffs. http://people.freebsd.org/~Pbin o __P -> deleted o conversion to new function declaration style o Deletion of main prototypes (per Peter's request) o Some register removal (but not all, I might do that too before the commit, per David O'Brien's suggestion). o Some style(9) tweaks: int foo() { } becomes int foo(void) { } o Some general fussiness that I couldn't help myself on. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 20:28:30 2002 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 AA31B37B400 for ; Thu, 31 Jan 2002 20:28: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 g114SQi40970; Thu, 31 Jan 2002 23:28:26 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020131.200942.41874592.imp@village.org> References: <20020131.200942.41874592.imp@village.org> Date: Thu, 31 Jan 2002 23:28:25 -0500 To: "M. Warner Losh" , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Bin diffs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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 8:09 PM -0700 1/31/02, M. Warner Losh wrote: >OK. Here's my first round of diffs. > >http://people.freebsd.org/~Pbin > >Comments? First comment is that I believe you wanted: http://people.freebsd.org/~imp/Pbin :-) -- 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 Jan 31 20:46:23 2002 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 DEBF937B404 for ; Thu, 31 Jan 2002 20:46:19 -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 g114kCi113676; Thu, 31 Jan 2002 23:46:12 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020131.200942.41874592.imp@village.org> References: <20020131.200942.41874592.imp@village.org> Date: Thu, 31 Jan 2002 23:46:11 -0500 To: "M. Warner Losh" , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Bin diffs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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 8:09 PM -0700 1/31/02, M. Warner Losh wrote: >OK. Here's my first round of diffs. > [...] > >o Some general fussiness that I couldn't help myself on. > >Comments? In the area of generally fussiness... You can't necessarily see it in the diff, but the prototype sections in different files have different ideas for tabbing. For instance, the new prototypes in +++ cat/cat.c +static void raw_cat(int); (ie, no tabs at all) +++ chio/chio.c +static void cleanup(void); (first word, , remainder of prototype) +++ dd/args.c +static int c_arg(const void *, const void *); (all words describing the return value, , remainder) -- 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 Jan 31 21:34:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 50FB937B404 for ; Thu, 31 Jan 2002 21:34:45 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g115Yih3010394; Fri, 1 Feb 2002 00:34:44 -0500 (EST) Date: Fri, 1 Feb 2002 00:34:44 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: KSE and SIGNALS (How to feel ill in 30 seconds) 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, 31 Jan 2002, Julian Elischer wrote: > Well, we have no real design yet for handling signals in > a multi-threaded process. > In the current statem the signals would be handled by whatever > thread is next returned to by the system, or > in fact if it is an upcall, it would be handled on the UTS stack if that > was next. (In the current incarnation, all syscalls return with an upcall > so quite a few signals would be handled on the UTS stack. Only syscalls that block should return via an upcall. Or am I misunderstanding something. For instance, getpid() should not result in an upcall. You'd add the cost of a context switch (even if is a userland switch) for every system call. And it's not just a context switch. An upcall event would probably force a check of the scheduling queue, locks would have to be taken, etc. Just make signals an upcall notification. The same thing has to happen in trying to deliver a signal as when a thread blocks in the kernel. The UTS gets notified of the event(s), handles the event(s), and chooses another thread to run. When a signal arrives, the UTS has to find a thread to handle it and schedule the thread to run. Once it finds a thread to handle the signal, it just elevates the threads priority, inserts it into the run queue, and chooses a new thread. Most likely, the same thread will be pulled from the run queue. > In other words whenever the next return to user space is > made after the signal is posted, the signal will be acted upon. That's fine as long as it is an upcall. > It is likely that we want to do something a little more > consitent than this. > > Some possibilities: > > * Leave it as it is.. The signals are done on whatever thread is > next, even if it is an upcall. Yes, we handle this now, but it isn't too pretty. > * A special upcall location is assigned for them. The upcall is > scheduled instead of whatever the next return to userland > would be (which is delayed). Whether it is a special upcall or not, I don't think it matters. But an upcall would be preferred, and we shouldn't get another upcall while we are currently in one (whether it is a signal upcall or the other kind(s)). > * They are returned only on upcalls (choosing the next one up) > (upcalls can be done at almost any time that there is not already > an upcall in progress). This is good. > * They are returned only on a particular upcall stack (but it > may not be active for a while, maybe we can force it to happen. POSIX says that signals should be delivered as soon as possible. That leaves a lot of room, but there is no reason why a signal event should be any different than any other event that generates an upcall. > * They are retunred only on a specified user thread, (but there > is nothing to say that the UTS will schedule that thread any time > soon. If the UTS wants to dedicate a special thread for signal delivery, that is its own business. From the kernels point of view, and since the kernel doesn't know anything about user threads, just notify the UTS of the signal event, and let the UTS deal with it the way it wants to. > * A separate signal stack is provided. Not an upcall, just dedicated. This isn't any different than the current system when sigaltstack is used. Each upcall has it's own stack, so I don't see this being useful. I've probably mentioned this a couple of times, but it may help you to know how signals should happen in a threaded application. There's no way the kernel can deliver the signal to the correct thread; only the UTS knows the state of all the threads, their masks, etc. When a signal is delivered to a thread, it really has to happen in the context of that thread. It can't easily be on any other stack than the threads own stack. So when the UTS sets up a thread to handle a signal, it's similar to the way the kernel delivers a signal (the old way). It adds a frame to the top of the threads stack that knows how to invoke the handler and return back to the threads interrupted context. Since the UTS has to fiddle with a threads stack to install a signal handler on it, it is easier if the signal notification to the UTS does _not_ happen on the stack of any thread; otherwise we have to make special exceptions for handling signals on the current thread. My preference is to have signals be upcall notifications of some sort. I don't see why they can't use the same upcall as other kernel events. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 31 23:40:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id BC9DE37B400 for ; Thu, 31 Jan 2002 23:40:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020201074007.WBIU10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 1 Feb 2002 07:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA65018; Thu, 31 Jan 2002 23:35:35 -0800 (PST) Date: Thu, 31 Jan 2002 23:35:33 -0800 (PST) From: Julian Elischer To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: KSE and SIGNALS (How to feel ill in 30 seconds) 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, 1 Feb 2002, Daniel Eischen wrote: > On Thu, 31 Jan 2002, Julian Elischer wrote: > > Well, we have no real design yet for handling signals in > > a multi-threaded process. > > In the current statem the signals would be handled by whatever > > thread is next returned to by the system, or > > in fact if it is an upcall, it would be handled on the UTS stack if that > > was next. (In the current incarnation, all syscalls return with an upcall > > so quite a few signals would be handled on the UTS stack. > > Only syscalls that block should return via an upcall. Or am > I misunderstanding something. For instance, getpid() should > not result in an upcall. You'd add the cost of a context > switch (even if is a userland switch) for every system call. > And it's not just a context switch. An upcall event would > probably force a check of the scheduling queue, locks would > have to be taken, etc. That is the aim, but to get things up and running fast I'm upcalling on all syscall returns. Not doing so is an optimisation we can add... but it cloudes some of the issues I want to test. > > Just make signals an upcall notification. The same thing has > to happen in trying to deliver a signal as when a thread blocks > in the kernel. The UTS gets notified of the event(s), handles > the event(s), and chooses another thread to run. When a signal > arrives, the UTS has to find a thread to handle it and schedule > the thread to run. Once it finds a thread to handle the signal, > it just elevates the threads priority, inserts it into the > run queue, and chooses a new thread. Most likely, the same > thread will be pulled from the run queue. > > > In other words whenever the next return to user space is > > made after the signal is posted, the signal will be acted upon. > > That's fine as long as it is an upcall. > > > It is likely that we want to do something a little more > > consitent than this. > > > > Some possibilities: > > > > * Leave it as it is.. The signals are done on whatever thread is > > next, even if it is an upcall. > > Yes, we handle this now, but it isn't too pretty. > > > * A special upcall location is assigned for them. The upcall is > > scheduled instead of whatever the next return to userland > > would be (which is delayed). > > Whether it is a special upcall or not, I don't think it matters. > But an upcall would be preferred, and we shouldn't get another > upcall while we are currently in one (whether it is a signal > upcall or the other kind(s)). > > > * They are returned only on upcalls (choosing the next one up) > > (upcalls can be done at almost any time that there is not already > > an upcall in progress). > > This is good. > > > * They are returned only on a particular upcall stack (but it > > may not be active for a while, maybe we can force it to happen. > > POSIX says that signals should be delivered as soon as possible. > That leaves a lot of room, but there is no reason why a signal > event should be any different than any other event that generates > an upcall. > > > * They are returned only on a specified user thread, (but there > > is nothing to say that the UTS will schedule that thread any time > > soon. > > If the UTS wants to dedicate a special thread for signal delivery, > that is its own business. From the kernels point of view, and > since the kernel doesn't know anything about user threads, just > notify the UTS of the signal event, and let the UTS deal with it > the way it wants to. The kernel DOES know SOMETHING about user threads.. It knows the address it should return state at on each syscall, should it block, and thus can "know" when a particular thread is running by assuming that whenever that address is given, that thread is working. it is really just a number, but the changes to ptrace will use that number to associate a thread with wether or not it should be single stepped or not. (it's a long story, bu you need soem way to know if the 'single step' but should be set for a returning thread or not. In thread mode, only a returning thread that is associated with a particular mailbox will be single stepping.) > > > * A separate signal stack is provided. Not an upcall, just dedicated. > > This isn't any different than the current system when sigaltstack > is used. Each upcall has it's own stack, so I don't see this > being useful. ok.. > > I've probably mentioned this a couple of times, but it may help > you to know how signals should happen in a threaded application. > There's no way the kernel can deliver the signal to the correct > thread; only the UTS knows the state of all the threads, their > masks, etc. When a signal is delivered to a thread, it really > has to happen in the context of that thread. It can't easily > be on any other stack than the threads own stack. So when the > UTS sets up a thread to handle a signal, it's similar to the > way the kernel delivers a signal (the old way). It adds a frame > to the top of the threads stack that knows how to invoke the > handler and return back to the threads interrupted context. > Since the UTS has to fiddle with a threads stack to install a > signal handler on it, it is easier if the signal notification > to the UTS does _not_ happen on the stack of any thread; > otherwise we have to make special exceptions for handling > signals on the current thread. Ok that makes it easy (approximatly) for me :-) > > My preference is to have signals be upcall notifications of > some sort. I don't see why they can't use the same upcall > as other kernel events. ok. what if there are multiple signals? do you want agregation? > > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 0:15:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 0464C37BA19 for ; Fri, 1 Feb 2002 00:14:09 -0800 (PST) Received: from pool0004.cvx22-bradley.dialup.earthlink.net ([209.179.198.4] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WYpi-0007Oo-00; Fri, 01 Feb 2002 00:14:06 -0800 Message-ID: <3C5A4E44.6380900B@mindspring.com> Date: Fri, 01 Feb 2002 00:13:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: FWIW... maybe this way already? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Linux did what I think is an incredibly clever thing. They put the current CPU at the beginning of the stack, and then change it when/if they migrate the process. Since KSEs have stacks, as well, you could put the process and thread ID after the CPU ID, there. Saves weirding out a register to get the CPU, PID, TID, since the stack base is always known. FWIW. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 1:38: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (f81.pav2.hotmail.com [64.4.37.81]) by hub.freebsd.org (Postfix) with ESMTP id B3E7237B41C for ; Fri, 1 Feb 2002 01:37:54 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 1 Feb 2002 01:37:54 -0800 Received: from 212.226.216.93 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 01 Feb 2002 09:37:54 GMT X-Originating-IP: [212.226.216.93] From: "Juha Juntunen" To: arch@FreeBSD.ORG Subject: Re: __P macro question Date: Fri, 01 Feb 2002 11:37:54 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2002 09:37:54.0707 (UTC) FILETIME=[1FEF2630:01C1AB04] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>static int sendfile __P((struct printer *pp, int type, char *file, >>> int format)); >>> >>>for a procedure declaration of: >>> static int >>> sendfile(pp, type, file, format) >>> struct printer *pp; >>> int type; >>> char *file; >>> char format; >>> { >> >>That's *EXCATLY* why I'm converting the old, but still legal in c89, >>style to new style. You get warnings that you didn't get before. > >The compiler is broken, if it accepts the second when the >first prototype is in scope. > >It's a broken compiler, period. How is the compiler broken, question mark. Are you perhaps objecting to the type of the last parameter ("int format" vs "char format")? Please see Ansi Classic, chapter "3.5.4.3 Function declarators (including prototypes)", in particular page 69 lines 19-22. In C99, 6.7.5.3 paragraph #11 seems to apply similarly. If you - define "__P" suitably - add "struct printer;" to file scope - add "}" to complete the function definition to me, the above code fragment seems to constitute a valid ANSI C89 translation unit. ++sja _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 2:53:55 2002 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 3059C37B416 for ; Fri, 1 Feb 2002 02:53:53 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16WbNC-000Og0-00 for arch@FreeBSD.org; Fri, 01 Feb 2002 12:56:50 +0200 From: Sheldon Hearn To: arch@FreeBSD.org Subject: Adding support for a global src tree serial number [FOLLOWUP] Date: Fri, 01 Feb 2002 12:56:50 +0200 Message-ID: <94859.1012561010@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 Hi folks, Just a quick note to say that I'm backing off this one, having heard about John Polstra's plans to build something that we can use as a reasonably accurate "snapshot identifier" into cvsup. Once John's new CVSup feature is in place, I'll revisit the PR. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 5:56:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 720B137B400 for ; Fri, 1 Feb 2002 05:56:14 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g11DuDjv007834; Fri, 1 Feb 2002 08:56:13 -0500 (EST) Date: Fri, 1 Feb 2002 08:56:13 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: KSE and SIGNALS (How to feel ill in 30 seconds) 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, 31 Jan 2002, Julian Elischer wrote: > On Fri, 1 Feb 2002, Daniel Eischen wrote: > > Only syscalls that block should return via an upcall. Or am > > I misunderstanding something. For instance, getpid() should > > not result in an upcall. You'd add the cost of a context > > switch (even if is a userland switch) for every system call. > > And it's not just a context switch. An upcall event would > > probably force a check of the scheduling queue, locks would > > have to be taken, etc. > > That is the aim, but to get things up and running fast > I'm upcalling on all syscall returns. > Not doing so is an optimisation we can add... > but it cloudes some of the issues I want to test. OK > > If the UTS wants to dedicate a special thread for signal delivery, > > that is its own business. From the kernels point of view, and > > since the kernel doesn't know anything about user threads, just > > notify the UTS of the signal event, and let the UTS deal with it > > the way it wants to. > > The kernel DOES know SOMETHING about user threads.. It knows the address > it should return state at on each syscall, should it block, and thus can > "know" when a particular thread is running by assuming that whenever that > address is given, that thread is working. it is really just a number, but > the changes to ptrace will use that number to associate a thread with > wether or not it should be single stepped or not. (it's a long story, bu > you need soem way to know if the 'single step' but should be set for a > returning thread or not. In thread mode, only a returning thread that is > associated with a particular mailbox will be single stepping.) Yep, I understand that the kernel knows where to store the current threads state, but I'm sure we agree that that's not enough info for the kernel to deliver signals to the correct thread. As far as debugging a multithreaded program, when I hit a breakpoint or something I would expect all threads to suspend. I should be able to switch between threads in the debugger and see where each one was. > > > > My preference is to have signals be upcall notifications of > > some sort. I don't see why they can't use the same upcall > > as other kernel events. > > ok. > what if there are multiple signals? do you want agregation? You can send them all at once in the same upcall if you want. For now, why don't you use the process' signal mask (in the same way as is currently done) to decide which signals can be sent. I can't really forsee why we would need to block any signals (since the UTS will know whether they are blocked and can make them pending if necessary). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 6: 3:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 602E037B404 for ; Fri, 1 Feb 2002 06:03:10 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g11E39hV008740; Fri, 1 Feb 2002 09:03:09 -0500 (EST) Date: Fri, 1 Feb 2002 09:03:09 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: FWIW... maybe this way already? In-Reply-To: <3C5A4E44.6380900B@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Feb 2002, Terry Lambert wrote: > Linux did what I think is an incredibly clever thing. > > They put the current CPU at the beginning of the stack, > and then change it when/if they migrate the process. The beginning of what stack? Each thread has its own stack that doesn't have to be the same size and stuff. We plan on using %gs for a pointer to a per-KSE or per-thread chunk of memory (and we could put anything in there). > Since KSEs have stacks, as well, you could put the > process and thread ID after the CPU ID, there. > > Saves weirding out a register to get the CPU, PID, TID, > since the stack base is always known. How is the stack base always known in a threaded process? Well, you know the process stack base, but that doesn't help. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 6:29:38 2002 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 0C84337B405 for ; Fri, 1 Feb 2002 06:29:34 -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 BAA16171; Sat, 2 Feb 2002 01:29:15 +1100 Date: Sat, 2 Feb 2002 01:31:23 +1100 (EST) From: Bruce Evans X-X-Sender: To: Juha Juntunen Cc: Subject: Re: __P macro question In-Reply-To: Message-ID: <20020202012011.U3304-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Feb 2002, Juha Juntunen wrote: > >>>static int sendfile __P((struct printer *pp, int type, char *file, > >>> int format)); > >>> > >>>for a procedure declaration of: > >>> static int > >>> sendfile(pp, type, file, format) > >>> struct printer *pp; > >>> int type; > >>> char *file; > >>> char format; > >>> { > >> > >>That's *EXCATLY* why I'm converting the old, but still legal in c89, > >>style to new style. You get warnings that you didn't get before. > > > >The compiler is broken, if it accepts the second when the > >first prototype is in scope. > > > >It's a broken compiler, period. > > How is the compiler broken, question mark. > > Are you perhaps objecting to the type of the last parameter > ("int format" vs "char format")? Please see Ansi Classic, chapter > "3.5.4.3 Function declarators (including prototypes)", in particular > page 69 lines 19-22. In C99, 6.7.5.3 paragraph #11 seems to apply > similarly. Right. I don't trust anyone who is not familiar with this point to globally remove __P. People removing __P should also be familiar with the gcc conterpoint: void foo(char); /* Wrong; should be "void foo(int);". */ void foo(c) char c; {} gives undefined behaviour in Standard C, but gcc defines its behaviour to be do-what-naive-programmer-expects. This is only safe provided the wrong prototype for foo() is always in scope before foo() is called; otherwise foo() is sometimes passed an int and sometimes a char, but foo() expects to be passed either an int or a char depending on whether the wrong prototype is in scope for the function body. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 6:40:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 71AAE37B419 for ; Fri, 1 Feb 2002 06:40:11 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g11Ee9g50529; Fri, 1 Feb 2002 14:40:09 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 983D157; Fri, 1 Feb 2002 14:38:01 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g11EbxE98677; Fri, 1 Feb 2002 14:38:00 GMT (envelope-from mark@grondar.za) Message-Id: <200202011438.g11EbxE98677@greenpeace.grondar.org> To: Bruce Evans Cc: Juha Juntunen , arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020202012011.U3304-100000@gamplex.bde.org> In-Reply-To: <20020202012011.U3304-100000@gamplex.bde.org> ; from Bruce Evans "Sat, 02 Feb 2002 01:31:23 +1100." Date: Fri, 01 Feb 2002 14:37:53 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Right. I don't trust anyone who is not familiar with this point to > globally remove __P. > > People removing __P should also be familiar with the gcc conterpoint: > > void foo(char); /* Wrong; should be "void foo(int);". */ > void foo(c) char c; {} > > gives undefined behaviour in Standard C, but gcc defines its behaviour > to be do-what-naive-programmer-expects. This is only safe provided the > wrong prototype for foo() is always in scope before foo() is called; > otherwise foo() is sometimes passed an int and sometimes a char, but > foo() expects to be passed either an int or a char depending on whether > the wrong prototype is in scope for the function body. So, does this not effectively make a rule, "You will _always_ properly prototype functions, and make sure that these proper prototypes are in scope before you use (and define) the functions."? M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 8:21:46 2002 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 0977937B405 for ; Fri, 1 Feb 2002 08:21:41 -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 DAA20950; Sat, 2 Feb 2002 03:20:48 +1100 Date: Sat, 2 Feb 2002 03:22:55 +1100 (EST) From: Bruce Evans X-X-Sender: To: Mark Murray Cc: Juha Juntunen , Subject: Re: __P macro question In-Reply-To: <200202011438.g11EbxE98677@greenpeace.grondar.org> Message-ID: <20020202031144.N3615-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Feb 2002, Mark Murray wrote: > > ... > > People removing __P should also be familiar with the gcc conterpoint: > > > > void foo(char); /* Wrong; should be "void foo(int);". */ > > void foo(c) char c; {} > > > > gives undefined behaviour in Standard C, but gcc defines its behaviour > > to be do-what-naive-programmer-expects. This is only safe provided the > > wrong prototype for foo() is always in scope before foo() is called; > > otherwise foo() is sometimes passed an int and sometimes a char, but > > foo() expects to be passed either an int or a char depending on whether > > the wrong prototype is in scope for the function body. > > So, does this not effectively make a rule, "You will _always_ properly > prototype functions, and make sure that these proper prototypes are in > scope before you use (and define) the functions."? Not quite. You can use lint to find arg mismatches. Even the 90%-finished lint in FreeBSD is effective compared with unavailable link-time checkers. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 8:53:17 2002 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 E7BFE37B419 for ; Fri, 1 Feb 2002 08:53:09 -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 g11Gr7o42156; Fri, 1 Feb 2002 09:53:07 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g11Gr5L03596; Fri, 1 Feb 2002 09:53:05 -0700 (MST) (envelope-from imp@village.org) Date: Fri, 01 Feb 2002 09:52:30 -0700 (MST) Message-Id: <20020201.095230.12730857.imp@village.org> To: bde@zeta.org.au Cc: estabur@hotmail.com, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <20020202012011.U3304-100000@gamplex.bde.org> References: <20020202012011.U3304-100000@gamplex.bde.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020202012011.U3304-100000@gamplex.bde.org> Bruce Evans writes: : > Are you perhaps objecting to the type of the last parameter : > ("int format" vs "char format")? Please see Ansi Classic, chapter : > "3.5.4.3 Function declarators (including prototypes)", in particular : > page 69 lines 19-22. In C99, 6.7.5.3 paragraph #11 seems to apply : > similarly. : : Right. I don't trust anyone who is not familiar with this point to : globally remove __P. So do I qualify? We all know that the original poster of the comment didn't understand this subtlty. :-) : People removing __P should also be familiar with the gcc conterpoint: : : void foo(char); /* Wrong; should be "void foo(int);". */ : void foo(c) char c; {} : : gives undefined behaviour in Standard C, but gcc defines its behaviour : to be do-what-naive-programmer-expects. This is only safe provided the : wrong prototype for foo() is always in scope before foo() is called; : otherwise foo() is sometimes passed an int and sometimes a char, but : foo() expects to be passed either an int or a char depending on whether : the wrong prototype is in scope for the function body. Alternatively: void foo(char); void foo(char c) { } would be right. :-) I've already found three places where this didn't hold. So what is the right style: 1) ^static void foo(char); 2) ^staticvoid foo(char); 3) ^static voidfoo(char); 4) ^staticvoidfoo(char); Most of the tree I've looked at so far uses #1. I'm a little reluctant to change that part of things on this pass. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 10: 0:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 0A7E437B400 for ; Fri, 1 Feb 2002 10:00:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020201180015.XXVA7443.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 1 Feb 2002 18:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA67167; Fri, 1 Feb 2002 10:00:00 -0800 (PST) Date: Fri, 1 Feb 2002 10:00:00 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: FWIW... maybe this way already? In-Reply-To: <3C5A4E44.6380900B@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG this is what mach threads did.. nowm the question is: how do you know where the beginning of the stack is? On Fri, 1 Feb 2002, Terry Lambert wrote: > Linux did what I think is an incredibly clever thing. > > They put the current CPU at the beginning of the stack, > and then change it when/if they migrate the process. > > Since KSEs have stacks, as well, you could put the > process and thread ID after the CPU ID, there. > > Saves weirding out a register to get the CPU, PID, TID, > since the stack base is always known. > > FWIW. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 10:22:54 2002 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 94C8637B400 for ; Fri, 1 Feb 2002 10:22:42 -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 FAA25879; Sat, 2 Feb 2002 05:19:52 +1100 Date: Sat, 2 Feb 2002 05:21:58 +1100 (EST) From: Bruce Evans X-X-Sender: To: "M. Warner Losh" Cc: , Subject: Re: __P macro question In-Reply-To: <20020201.095230.12730857.imp@village.org> Message-ID: <20020202045410.U4512-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Feb 2002, M. Warner Losh wrote: > In message: <20020202012011.U3304-100000@gamplex.bde.org> > Bruce Evans writes: > : > Are you perhaps objecting to the type of the last parameter > : > ("int format" vs "char format")? Please see Ansi Classic, chapter > : > "3.5.4.3 Function declarators (including prototypes)", in particular > : > page 69 lines 19-22. In C99, 6.7.5.3 paragraph #11 seems to apply > : > similarly. > : > : Right. I don't trust anyone who is not familiar with this point to > : globally remove __P. > > So do I qualify? We all know that the original poster of the comment > didn't understand this subtlty. :-) Better than the original poster :-). The original poster did md5 regression checks which would help. I think the global changes should just stay away from areas that can't be checked automatically. > : People removing __P should also be familiar with the gcc conterpoint: > : > : void foo(char); /* Wrong; should be "void foo(int);". */ > : void foo(c) char c; {} > : > : gives undefined behaviour in Standard C, but gcc defines its behaviour > : to be do-what-naive-programmer-expects. This is only safe provided the > : wrong prototype for foo() is always in scope before foo() is called; > : otherwise foo() is sometimes passed an int and sometimes a char, but > : foo() expects to be passed either an int or a char depending on whether > : the wrong prototype is in scope for the function body. > > Alternatively: > void foo(char); > void foo(char c) { } > would be right. :-) I've already found three places where this didn't > hold. It's as right as the gcc rewriting of the function definition, but is a semantic change and it should be checked carefully. gcc on i386's seems to have stopped pessimizing it; gcc on i386's doesn't optimize it either (for compatibility with binary interfaces suitable for K&R compilers :-(), so there is some change of checking the change automatically. > So what is the right style: > > 1) ^static void foo(char); > 2) ^staticvoid foo(char); > 3) ^static voidfoo(char); > 4) ^staticvoidfoo(char); > > Most of the tree I've looked at so far uses #1. I'm a little > reluctant to change that part of things on this pass. Most of it doesn't use static yet, and the KNF parts use: ^voidfoo __P((int)); I would just substitute away '__P((' and change '))' at the end of the same lines as __P(( to to ')', and not touch any other whitespace. Lines that don't match the simple regexp for this probably have style problems, e.g., ones involving line breaks for long lines. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 10:24:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 232EE37B41B for ; Fri, 1 Feb 2002 10:24:42 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g11IOfWW017380; Fri, 1 Feb 2002 13:24:41 -0500 (EST) Date: Fri, 1 Feb 2002 13:24:41 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: FWIW... maybe this way already? 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, 1 Feb 2002, Julian Elischer wrote: > this is what mach threads did.. > nowm the question is: how do you know where the beginning of the stack is? This has been discussed in the past. No, we don't know where the stack is or where it starts. Supporting POSIX threads prevents the implementation from always using a standard stack size (see pthread_attr_setstackaddr, pthread_attr_setstacksize). > On Fri, 1 Feb 2002, Terry Lambert wrote: > > > Linux did what I think is an incredibly clever thing. > > > > They put the current CPU at the beginning of the stack, > > and then change it when/if they migrate the process. > > > > Since KSEs have stacks, as well, you could put the > > process and thread ID after the CPU ID, there. > > > > Saves weirding out a register to get the CPU, PID, TID, > > since the stack base is always known. > > > > FWIW. > > > > -- Terry -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 12:59: 5 2002 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 126CF37B404 for ; Fri, 1 Feb 2002 12:59:02 -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 g11Kwc969134; Fri, 1 Feb 2002 15:58:38 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020202045410.U4512-100000@gamplex.bde.org> References: <20020202045410.U4512-100000@gamplex.bde.org> Date: Fri, 1 Feb 2002 15:58:39 -0500 To: Bruce Evans , "M. Warner Losh" From: Garance A Drosihn Subject: Re: __P macro question Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-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:21 AM +1100 2/2/02, Bruce Evans wrote: >On Fri, 1 Feb 2002, M. Warner Losh wrote: > > > So do I qualify? We all know that the original poster of the > > comment didn't understand this subtlty. :-) > >Better than the original poster :-). The original poster did md5 >regression checks which would help. I think the global changes >should just stay away from areas that can't be checked automatically. Okay, okay. As the "original poster" I'll admit that I am not an encyclopedia of C knowledge... :-) Still, if the routine is only *using* a char's worth of the incoming parameter, I would prefer the prototype defines the parameter as 'char' and not 'int'. That's just my personal preference, based on an upbringing which involved languages other than C. [and yes, I do understand how C passes parameters, and I guess I can see why there might be some logic in the prototype defining it as 'int' -- but I just don't like doing that] -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 16:31: 4 2002 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 1349637B400 for ; Fri, 1 Feb 2002 16:30:58 -0800 (PST) Received: from pool0542.cvx40-bradley.dialup.earthlink.net ([216.244.44.32] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Wo4V-0002Xb-00; Fri, 01 Feb 2002 16:30:25 -0800 Message-ID: <3C5B3315.3F07A731@mindspring.com> Date: Fri, 01 Feb 2002 16:30:13 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Bruce Evans , Juha Juntunen , arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020202012011.U3304-100000@gamplex.bde.org> <200202011438.g11EbxE98677@greenpeace.grondar.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 Mark Murray wrote: > So, does this not effectively make a rule, "You will _always_ properly > prototype functions, and make sure that these proper prototypes are in > scope before you use (and define) the functions."? I think it means "The compiler SHALL complain if this is not so". Right now, it doesn't complain. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 16:55: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id C8B6637B42B for ; Fri, 1 Feb 2002 16:54:08 -0800 (PST) Received: from pool0542.cvx40-bradley.dialup.earthlink.net ([216.244.44.32] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WoRR-0000IG-00; Fri, 01 Feb 2002 16:54:05 -0800 Message-ID: <3C5B38A7.87322161@mindspring.com> Date: Fri, 01 Feb 2002 16:53:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: FWIW... maybe this way already? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > this is what mach threads did.. > nowm the question is: how do you know where the beginning of the stack is? Hah! I _knew_ it tickled a memory! But to answer... User space register pointing to the stack for each system call, before the switch to the kernel stack. You can either maintain a list of stack bases, as instanced, passed into the kernel, in which case when you later get a thread entry, you can bsearch them, or you can search each time backwards to the unmapped page, with a guarantee of a page boundary start (this would be slow enough that it would outweight the advantages of doing this, IMO). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 20:26: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 885) id 48CFE37B47B; Fri, 1 Feb 2002 20:26:04 -0800 (PST) Date: Fri, 1 Feb 2002 20:26:03 -0800 From: Eric Melville To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number Message-ID: <20020201202603.A69486@FreeBSD.org> References: <79300.1012474898@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Thu, Jan 31, 2002 at 01:01:38PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. > > Essentially, the serial number lives in a file, the name of which is > not important until I have buy-in on the concept. Let's call it > src/SERIAL for now. Yes, I'll need to do something along these lines for binary updates. I think about it occasionally but haven't come up with anything concrete. It sounds like you're on to something, although for my purposes the mechanism must be more fine-grained. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 20:27: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 885) id A233C37B402; Fri, 1 Feb 2002 20:27:07 -0800 (PST) Date: Fri, 1 Feb 2002 20:27:07 -0800 From: Eric Melville To: "Jacques A. Vidrine" Cc: Sheldon Hearn , arch@FreeBSD.org Subject: Re: Adding support for a global src tree serial number Message-ID: <20020201202707.B69486@FreeBSD.org> References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020131131714.GA87780@madman.nectar.cc>; from n@nectar.cc on Thu, Jan 31, 2002 at 07:17:15AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This is attractive to me, since we already do something like this for > the `security' branches (RELENG_4_3 et al). We manually bump $BRANCH > in newvers.sh. I imagine it would also be attractive to people on > freebsd-binup. Yes, very much so. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 20:36:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 885) id D62A337B405; Fri, 1 Feb 2002 20:36:13 -0800 (PST) Date: Fri, 1 Feb 2002 20:36:13 -0800 From: Eric Melville To: The Anarcat Cc: "Jacques A. Vidrine" , Sheldon Hearn , arch@FreeBSD.org Subject: Re: tee versionning in npkg (Re: Adding support for a global src tree serial number) Message-ID: <20020201203613.C69486@FreeBSD.org> References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> <20020131171036.GA295@shall.anarcat.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: <20020131171036.GA295@shall.anarcat.dyndns.org>; from anarcat@anarcat.dyndns.org on Thu, Jan 31, 2002 at 12:10:36PM -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 libh package system still needs some work, but when it is ready, I > will start the packaging of /usr/src. I hope the tendency will not to > package it as a single package, and I even hope to package it as > finer-grained package than current "distributions" (bin, doc, contrib, > etc). Something more like: fileutils, binutils, gnu-binutils, openssh, > openssl, etc. That's the plan. > These packages will all have independant package numbers. These will > have to be maintained, somehow, and this is the main problem of the > packaging of /usr/src: it is not made for that yet. No support is > engineered in /usr/src to allow distribution and versionning of > packages. > > Serial number is one thing, and it might be a good idea, but we could > also consider more "classic" version numbers for sub-trees, as > openssh-2001013109910000008 is not really a "user-friendly" package > name. :) I'm hoping to actually make use of such stamp-style versions, while maintaining more friendly numbers simply for the purpose of being friendly. This way we'd end up with packages named things like filetools 4.5-STABLE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 1 23:12:36 2002 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 2A25D37B400 for ; Fri, 1 Feb 2002 23:12:32 -0800 (PST) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g127CV640056 for ; Fri, 1 Feb 2002 23:12:31 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.6) id g127D6Z00720 for arch@FreeBSD.org; Fri, 1 Feb 2002 23:13:06 -0800 (PST) (envelope-from marcel) Date: Fri, 1 Feb 2002 23:13:06 -0800 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: install(1) to use a cross strip(1) Message-ID: <20020201231306.A670@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, As part of doing cross development with our source tree I hit upon the nasty habit of install(1) to want to use strip(1) and specificly by that name. To make my live easier, I have made install(1) look for an envvar first. Is this kind of flexibility generic enough to have it committed? --- xinstall.c 19 Dec 2001 06:05:42 -0000 1.47 +++ xinstall.c 27 Jan 2002 08:54:51 -0000 @@ -702,6 +702,7 @@ strip(to_name) const char *to_name; { + char *stripbin; int serrno, status; switch (fork()) { @@ -711,7 +712,10 @@ errno = serrno; err(EX_TEMPFAIL, "fork"); case 0: - execlp("strip", "strip", to_name, (char *)NULL); + stripbin = getenv("STRIPBIN"); + if (stripbin == NULL) + stripbin = "strip"; + execlp(stripbin, stripbin, to_name, (char *)NULL); err(EX_OSERR, "exec(strip)"); default: if (wait(&status) == -1 || status) { NOTE: I use STRIPBIN, because STRIP is already taken (see /usr/share/mk). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 2 14:40:20 2002 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 0B80137B402 for ; Sat, 2 Feb 2002 14:40:15 -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 g12MeDo51084; Sat, 2 Feb 2002 15:40:13 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g12MeCL14691; Sat, 2 Feb 2002 15:40:12 -0700 (MST) (envelope-from imp@village.org) Date: Sat, 02 Feb 2002 15:39:41 -0700 (MST) Message-Id: <20020202.153941.85552167.imp@village.org> To: bde@zeta.org.au Cc: drosih@rpi.edu, deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <20020131231008.P4085-100000@gamplex.bde.org> References: <20020130.145424.00452635.imp@village.org> <20020131231008.P4085-100000@gamplex.bde.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020131231008.P4085-100000@gamplex.bde.org> Bruce Evans writes: : On Wed, 30 Jan 2002, M. Warner Losh wrote: : : > I'm going through bin right now removing __P() and making the : > functions have new-style rather than old-style decls. It is a nice : > little mindless thing to do when to relax and unwind. I plan on : > committing this this weekend (see below). I've seen nothing so far to : > tell me not to do it: : : Don't do it all. Some people prefer old-style decls, and unlike __P(()), : they don't involve any preprocessor hackery; they are part of ISO C. From The last draft of the latest C standard: Introduction [#2] Certain features are obsolescent, which means that they may be considered for withdrawal in future revisions of this International Standard. They are retained because of their widespread use, but their use in new implementations (for implementation features) or new programs (for language [6.11] or library features [7.26]) is discouraged. 6.11.4 Function definitions [#1] The use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators) is an obsolescent feature. I'm going to the trouble of doing it now because we'll have to do it eventually. It is sufficiently painful that I may stop doing it for the larger src.bin, src.sbin directories. At some point we're going to have to do this, why not now. I know that standard is a bit vague about the timeframe, but I suspect that if we eliminate them from our code base, that will be one less dusty deck to be used as justification for keeping the feature. Now is a good time for me because I have a lot of stress in my life and doing cleaning like this helps me relax. :-) : - be sure to unsort the prototypes and add excessive indentation to them. : Using a low quality script to regenerate all the prototypes is a good : way to do this. Sure. I'll see what I can do :-) I can also indent them in odd ways, use reserved words for the parameter names and try to omit types when they are ints. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 2 15:28:45 2002 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 0941437B404 for ; Sat, 2 Feb 2002 15:28:43 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id EB0EB5341; Sun, 3 Feb 2002 00:28:40 +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: Bruce Evans Cc: "M. Warner Losh" , , , Subject: Re: __P macro question References: <20020131231008.P4085-100000@gamplex.bde.org> From: Dag-Erling Smorgrav Date: 03 Feb 2002 00:28:40 +0100 In-Reply-To: <20020131231008.P4085-100000@gamplex.bde.org> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans writes: > When removing __P(()), don't do it like login/login.c rev.1.80: > - mix the removal with nontrivial rewriting of the code to make it harder > for auditors to see the critical changes. Change all the function > headers too, but don't de-verbosify the code by removing the prototypes > made redundant by this. > - be sure to unsort the prototypes and add excessive indentation to them. > Using a low quality script to regenerate all the prototypes is a good > way to do this. > ;-) STFU, Bruce. I can understand that you're bitter about losing the __P() argument, but this kind of sniping is beneath even you. Since you're so eager to deal out advice, allow me to present you with a piece of my own: stop patronizing your fellow committers. People might be more inclined to listen to you if you spent more time mailing out patches and less time lecturing. You're getting more and more like Terry every day. 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 Feb 2 16:41:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 15C9237B404; Sat, 2 Feb 2002 16:41:39 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 763B310; Sat, 2 Feb 2002 18:41:38 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g130fc449045; Sat, 2 Feb 2002 18:41:38 -0600 (CST) (envelope-from nectar) Date: Sat, 2 Feb 2002 18:41:38 -0600 From: "Jacques A. Vidrine" To: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/bin/cat cat.c Message-ID: <20020203004138.GA49024@madman.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-arch@freebsd.org References: <20020202165642.GA47737@madman.nectar.cc> <20020202.110822.04677583.imp@village.org> <15452.27501.263648.295757@caddis.yogotech.com> <20020202174556.A66107@hellblazer.nectar.cc> <20020203002859.GH58614@squall.waterspout.com> <200202020610.g126A1U15414@freefall.freebsd.org> <20020202165642.GA47737@madman.nectar.cc> <20020202.110822.04677583.imp@village.org> <15452.27501.263648.295757@caddis.yogotech.com> <20020202174556.A66107@hellblazer.nectar.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020203002859.GH58614@squall.waterspout.com> <20020202174556.A66107@hellblazer.nectar.cc> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Feb 02, 2002 at 07:29:00PM -0500, Will Andrews wrote: > On Sat, Feb 02, 2002 at 05:45:56PM -0600, Jacques A. Vidrine wrote: > > Oh great, now we can have a thread from hell about whether or not to > > merge these changes. > > And you picked the worst possible list to start it on. Yes, you're right [1]. Sorry, I misrembered which list the topic orignally came up on. I've set follow-ups to freebsd-arch, and I'm including the text you snipped below for context. > On Sat, Feb 02, 2002 at 03:42:53PM -0700, Nate Williams wrote: > > > : > imp 2002/02/01 22:10:01 PST > > > : > > > > : > Modified files: > > > : > bin/cat cat.c > > > : > Log: > > > : > Drag cat(1) kicking and screaming into the late 1980's: > > > : > > > : [for all such updates:] > > > : > > > : MFC after: ? > > > > > > I didn't plan on MFCing at this time. > > > > Thank you (not not merging it)!! > > Oh great, now we can have a thread from hell about whether or not to > merge these changes. > > One of the strongest arguments against making this change was due to > the problems it might create with tracking changes against the other > BSDs. I would like to see these changes MFC'd at some point so that > they do not create problems with tracking changes between our own > branches. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 2 17:13:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 7625237B400 for ; Sat, 2 Feb 2002 17:13:04 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 4463110DDF8; Sat, 2 Feb 2002 17:13:04 -0800 (PST) Date: Sat, 2 Feb 2002 17:13:04 -0800 From: Bill Fumerola To: Dag-Erling Smorgrav Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020202171304.E402@elvis.mu.org> Reply-To: Bill Fumerola References: <20020131231008.P4085-100000@gamplex.bde.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 Sun, Feb 03, 2002 at 12:28:40AM +0100 X-Operating-System: FreeBSD 4.5-FEARSOME-20011222 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, Feb 03, 2002 at 12:28:40AM +0100, Dag-Erling Smorgrav wrote: > Bruce Evans writes: > > When removing __P(()), don't do it like login/login.c rev.1.80: > > - mix the removal with nontrivial rewriting of the code to make it harder > > for auditors to see the critical changes. Change all the function > > headers too, but don't de-verbosify the code by removing the prototypes > > made redundant by this. > > - be sure to unsort the prototypes and add excessive indentation to them. > > Using a low quality script to regenerate all the prototypes is a good > > way to do this. > > ;-) > > STFU, Bruce. I can understand that you're bitter about losing the > __P() argument, but this kind of sniping is beneath even you. > > Since you're so eager to deal out advice, allow me to present you with > a piece of my own: stop patronizing your fellow committers. People > might be more inclined to listen to you if you spent more time mailing > out patches and less time lecturing. You're getting more and more > like Terry every day. you can lay out pages and pages of criticism, personal and unprofessional attacks of others (see recent ache thread, for starters) but can't handle two much nicer, non-personal paragraphs about some code you wrote? grow up or get some thicker skin or at least leave it off -arch. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 2 17:39:35 2002 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 B391137B400 for ; Sat, 2 Feb 2002 17:39:32 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2A4BD5341; Sun, 3 Feb 2002 02:39:31 +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: Bill Fumerola Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020131231008.P4085-100000@gamplex.bde.org> <20020202171304.E402@elvis.mu.org> From: Dag-Erling Smorgrav Date: 03 Feb 2002 02:39:30 +0100 In-Reply-To: <20020202171304.E402@elvis.mu.org> Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 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 Bill Fumerola writes: > you can lay out pages and pages of criticism, personal and unprofessional > attacks of others (see recent ache thread, for starters) but can't handle > two much nicer, non-personal paragraphs about some code you wrote? I generally try to include the person I'm criticizing in the conversation. I also generally try to base my criticism on fact, not on speculation. 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