From owner-freebsd-arch@FreeBSD.ORG Mon Apr 30 21:00:40 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C29FA16A401; Mon, 30 Apr 2007 21:00:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 65F3213C483; Mon, 30 Apr 2007 21:00:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3UL0Xpr016564; Mon, 30 Apr 2007 17:00:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 30 Apr 2007 15:41:22 -0400 User-Agent: KMail/1.9.6 References: <200704262136.33196.hselasky@c2i.net> <46323A77.8010907@elischer.org> <200704272032.20664.hselasky@freebsd.org> In-Reply-To: <200704272032.20664.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704301541.23678.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Apr 2007 17:00:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3184/Mon Apr 30 09:51:57 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Daniel Eischen , Attilio Rao , freebsd-arch@freebsd.org, Hans Petter Selasky , Julian Elischer Subject: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2007 21:00:40 -0000 On Friday 27 April 2007 02:32:20 pm Hans Petter Selasky wrote: > > > P0 unlock(1); > > > P0 unlock(2); > > > > this looks "interesting". > > Can you give a more concrete example of this? > > what work is done in the upcall? WHo is upcalling to who? > > For example an USB device driver might be up-calling to the USB host > controller driver. Down call is when the transfer finishes. I think in this case you don't want to keep the periph locked while you ask the controller to process requests. Instead, the periph drivers should queue requests to the controller and receive replies, but they should be considered as two independent objects. For example, network drivers drop their lock when passing a packet (request) up the stack. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue May 1 07:02:14 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E302716A402; Tue, 1 May 2007 07:02:14 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECA613C465; Tue, 1 May 2007 07:02:12 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 1A0BE2087; Tue, 1 May 2007 09:02:09 +0200 (CEST) X-Spam-Tests: AWL,MAILTO_TO_SPAM_ADDR X-Spam-Learn: disabled X-Spam-Score: 0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id EE71D2086; Tue, 1 May 2007 09:02:08 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id CBE7C5675; Tue, 1 May 2007 09:02:08 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Takeharu KATO References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> Date: Tue, 01 May 2007 09:02:08 +0200 In-Reply-To: <4633932A.8080602@ybb.ne.jp> (Takeharu KATO's message of "Sun, 29 Apr 2007 03:32:10 +0900") Message-ID: <86tzuxni1b.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2007 07:02:15 -0000 Takeharu KATO writes: > I wrote ICH7 or later support patch for sys/dev/ichwd watch dog driver. > I tested this patch on ICH8 compliant mother board(GIGA BYTE GA-965P-DS3). > > Please apply the patch. I will try to take care of this some time within the next two weeks. Feel free to contact me off-list if you have any updates. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue May 1 22:41:20 2007 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E17516A408; Tue, 1 May 2007 22:41:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B7CA613C44B; Tue, 1 May 2007 22:41:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l41MdTpA015405; Tue, 1 May 2007 16:39:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 01 May 2007 16:39:41 -0600 (MDT) Message-Id: <20070501.163941.-2001109237.imp@bsdimp.com> To: ache@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20070501193146.GD10323@nagual.pp.ru> References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <200705011210.12839.jhb@freebsd.org> <20070501193146.GD10323@nagual.pp.ru> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 01 May 2007 16:39:30 -0600 (MDT) Cc: alfred@FreeBSD.ORG, jhb@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2007 22:41:20 -0000 Andrey, Thanks for taking the time to track down all the problems that the initial commit caused. Thank you also for showing the maturity to gracefully back out the changes until they can be discussed in more depth. I know that there's been a lot of emotion expressed over these changes, and I complement you on keeping your cool during the discussions. I'd like to suggest that people interested in this continue the discussion in arch@ which is a more appropriate... This post seems to be the most relevant of the ones from src-commits. Warner In message: <20070501193146.GD10323@nagual.pp.ru> Andrey Chernov writes: : On Tue, May 01, 2007 at 12:10:11PM -0400, John Baldwin wrote: : > Now, that said, apparently some folks on this list CAN'T READ. : > : > Linux has the new putenv() algorithm already, so if any software breaks with : > this, it is _ALREADY_ broken on Linux. Please consider that before ripping : > ache@ a new one here. As much as BSD wants to feel really important, in : > truth, most of the software in ports probably runs more often on Linux than : > on BSD, so I think the chances of non-trivial real-world breakage are fairly : > small. : : And I already tell exactly so about Linux and ports already portable in : the threads. Perhaps they will hear you better, but the changes in : question are already backed out and I can't work on them under such : pressure. In case anyone brave will be found, feel free to restore, and : then I'll promise my help dealing with all bugs they may cause. : : > So with all that said, it seems we have four groups of usage with respect to : > putenv(3): : > : > - give it a stack allocated or otherwise non-persistent buffer (note that : > string constants are persistent, even if they are read-only) as the first : > argument. This violates POSIX I guess, and would break on at least Linux and : > Solaris (judging by Open Solaris's putenv() implementation). : : Agreed. : : > - pass in a persistent buffer (constant, allocated memory, etc.) and change : > the contents later expecting that changing the buffer won't change the : > environment. This breaks Linux and Solaris and POSIX as well. : : Agreed. : : > - pass in a persistent buffer and don't change it afterwards (at least not : > until after a later call to putenv or setenv for the same variable). This : > works for both impls and is probably the vast majority of usage. : : Agreed. Most programs don't use the modify-env-on-the-fly feature, but it : is at the current moment, just because several putenv() implementations : was hanging around when no one standartized. When POSIX explicitly : standartize modify-env-on-the-fly feature, more programs will tend to try : it at time. : : > - pass in a persistent buffer and change the contents expecting that it will : > change the value returned from getenv(). This doesn't work on BSD, but does : > on Linux + Solaris + POSIX + FreeBSD 7. : : Agreed (but not for FreeBSD7 now). : : > So we have four groups: 1, 2, 3 (likely the vast majority), and 4. (4) is : > fixed by this commit, and works on Linux, Solaris, and POSIX. (1 + 2) are : > broken by this commit, but they also don't work on Linux, Solaris, or POSIX. : > So the question seems to be, which set is larger, programs that depend on (1 + : > 2), or programs that depend on (4)? Also, which set is going to get larger : > as time moves on given Linux's implementation? If you assume (as I do), that : > most programs fall into (3) anyway, then it really isn't all that important : > anyway. : : Set 3 is larger now, but popularity of set 4 perhaps will be increased in : the future because it is standard. Set 1 is small and will be decreased. : : -- : http://ache.pp.ru/ : From owner-freebsd-arch@FreeBSD.ORG Tue May 1 22:58:16 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06F6016A401 for ; Tue, 1 May 2007 22:58:16 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id AE59A13C468 for ; Tue, 1 May 2007 22:58:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l41MgOqZ012798; Tue, 1 May 2007 18:42:24 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Tue, 01 May 2007 18:42:24 -0400 (EDT) Date: Tue, 1 May 2007 18:42:24 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20070501.163106.1159135672.imp@bsdimp.com> Message-ID: References: <200705011602.l41G2iRx003626@repoman.freebsd.org> <20070501.163106.1159135672.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib getenv.3 getenv.c putenv.c setenv.c src/sys/sys param.h src/usr.bin/limits limits.c src/usr.bin/env env.c src/usr.sbin/sysinstall main.c variable.c src/usr.sbin/pstat pstat.c src/usr.sbin/sade main.c variable.c ... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2007 22:58:16 -0000 [ taken to -arch ] On Tue, 1 May 2007, M. Warner Losh wrote: > In message: > Daniel Eischen writes: > : On Tue, 1 May 2007, Andrey A. Chernov wrote: > : > : > ache 2007-05-01 16:02:44 UTC > : > > : > FreeBSD src repository ... > : > Log: > : > Back out all POSIXified *env() changes. > : > > : > Not because I admit they are technically wrong and not because of bug > : > reports (I receive nothing). But because I surprisingly meets so > : > strong opposition and resistance so lost any desire to continue that. > : > : Uh, please put them back in. This is -current and we do want > : to be conformant with POSIX where possible. > > PLEASE! > > Let's have a discussion on arch@ about the issues with doing this > before we make more changes! Sorry, it looked like the discussion already happened to me, and I wasn't convinced by the opponents of the change. By all means, feel free to discuss it more if you'd like. -- DE From owner-freebsd-arch@FreeBSD.ORG Tue May 1 23:32:12 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AA3E16A400 for ; Tue, 1 May 2007 23:32:12 +0000 (UTC) (envelope-from www@master.netart.cz) Received: from master.netart.cz (88-128-158-212.bluetone.cz [212.158.128.88]) by mx1.freebsd.org (Postfix) with ESMTP id D0F4E13C45E for ; Tue, 1 May 2007 23:32:11 +0000 (UTC) (envelope-from www@master.netart.cz) Received: from master.netart.cz (localhost [127.0.0.1]) by master.netart.cz (8.13.8/8.13.8) with ESMTP id l41MlFld099351 for ; Wed, 2 May 2007 00:47:15 +0200 (CEST) (envelope-from www@master.netart.cz) Received: (from www@localhost) by master.netart.cz (8.13.8/8.13.8/Submit) id l41MlEG2099350; Wed, 2 May 2007 00:47:14 +0200 (CEST) (envelope-from www) Date: Wed, 2 May 2007 00:47:14 +0200 (CEST) Message-Id: <200705012247.l41MlEG2099350@master.netart.cz> To: freebsd-arch@freebsd.org From: James MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, FORGED_YAHOO_RCVD autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on master.netart.cz X-Virus-Scanned: ClamAV 0.88/3190/Tue May 1 23:06:04 2007 on master.netart.cz X-Virus-Status: Clean Subject: Pet Advert..... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmarc112@yahoo.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2007 23:32:12 -0000 Hello, I will like to place a print Ad on your newspaper and i will like to know the cost for 30 days/4 weeks.kindly get back to me now with the quote,so that i can forward my credit card for the payment. Description below to be on newspaper: BRITISH BULLDOGS PUPPIES FOR-SALE! Beautiful colour and features. Loves to CUDDLE! Short cobby body style.Bulldogs of Stokes Ridge have puppies ready to be a part of your family,Our English Bulldogs are raised in our home with our children. We are not a kennel. Puppies come to you with AKC papers, up to date shots, and health records.Champion Bloodline puppies for sale to approved pet homes only. Breed: English Bulldog Gender: Female & Male are available For Further Enquiry About The Bulldogs Puppies,Email: steve_barrick00@yahoo.com ----------------------------------------------------- Here are the details to be on the newspaper above,get back to me with the quote so that i can email you with the credit cards for the payment Regards James Email me with the cost to these email address: jmarc112@yahoo.com From owner-freebsd-arch@FreeBSD.ORG Wed May 2 14:53:10 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C42BA16A403; Wed, 2 May 2007 14:53:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9C413C458; Wed, 2 May 2007 14:53:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l42Er2hq031670; Wed, 2 May 2007 10:53:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 2 May 2007 10:45:00 -0400 User-Agent: KMail/1.9.6 References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <20070501193146.GD10323@nagual.pp.ru> <20070501.163941.-2001109237.imp@bsdimp.com> In-Reply-To: <20070501.163941.-2001109237.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705021045.01221.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 02 May 2007 10:53:03 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3195/Wed May 2 05:34:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, alfred@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 14:53:10 -0000 On Tuesday 01 May 2007 06:39:41 pm M. Warner Losh wrote: > Andrey, > > Thanks for taking the time to track down all the problems that the > initial commit caused. Thank you also for showing the maturity to > gracefully back out the changes until they can be discussed in more > depth. I know that there's been a lot of emotion expressed over these > changes, and I complement you on keeping your cool during the > discussions. > > I'd like to suggest that people interested in this continue the > discussion in arch@ which is a more appropriate... This post seems to > be the most relevant of the ones from src-commits. If it wasn't obvious from my post, I think that the POSIX putenv(3) is probably the most beneficial going forward. It also doesn't impact the setenv(3) memory fixes, which should also probably go in once someone has reviewed them. > Warner > > In message: <20070501193146.GD10323@nagual.pp.ru> > Andrey Chernov writes: > : On Tue, May 01, 2007 at 12:10:11PM -0400, John Baldwin wrote: > : > Now, that said, apparently some folks on this list CAN'T READ. > : > > : > Linux has the new putenv() algorithm already, so if any software breaks with > : > this, it is _ALREADY_ broken on Linux. Please consider that before ripping > : > ache@ a new one here. As much as BSD wants to feel really important, in > : > truth, most of the software in ports probably runs more often on Linux than > : > on BSD, so I think the chances of non-trivial real-world breakage are fairly > : > small. > : > : And I already tell exactly so about Linux and ports already portable in > : the threads. Perhaps they will hear you better, but the changes in > : question are already backed out and I can't work on them under such > : pressure. In case anyone brave will be found, feel free to restore, and > : then I'll promise my help dealing with all bugs they may cause. > : > : > So with all that said, it seems we have four groups of usage with respect to > : > putenv(3): > : > > : > - give it a stack allocated or otherwise non-persistent buffer (note that > : > string constants are persistent, even if they are read-only) as the first > : > argument. This violates POSIX I guess, and would break on at least Linux and > : > Solaris (judging by Open Solaris's putenv() implementation). > : > : Agreed. > : > : > - pass in a persistent buffer (constant, allocated memory, etc.) and change > : > the contents later expecting that changing the buffer won't change the > : > environment. This breaks Linux and Solaris and POSIX as well. > : > : Agreed. > : > : > - pass in a persistent buffer and don't change it afterwards (at least not > : > until after a later call to putenv or setenv for the same variable). This > : > works for both impls and is probably the vast majority of usage. > : > : Agreed. Most programs don't use the modify-env-on-the-fly feature, but it > : is at the current moment, just because several putenv() implementations > : was hanging around when no one standartized. When POSIX explicitly > : standartize modify-env-on-the-fly feature, more programs will tend to try > : it at time. > : > : > - pass in a persistent buffer and change the contents expecting that it will > : > change the value returned from getenv(). This doesn't work on BSD, but does > : > on Linux + Solaris + POSIX + FreeBSD 7. > : > : Agreed (but not for FreeBSD7 now). > : > : > So we have four groups: 1, 2, 3 (likely the vast majority), and 4. (4) is > : > fixed by this commit, and works on Linux, Solaris, and POSIX. (1 + 2) are > : > broken by this commit, but they also don't work on Linux, Solaris, or POSIX. > : > So the question seems to be, which set is larger, programs that depend on (1 + > : > 2), or programs that depend on (4)? Also, which set is going to get larger > : > as time moves on given Linux's implementation? If you assume (as I do), that > : > most programs fall into (3) anyway, then it really isn't all that important > : > anyway. > : > : Set 3 is larger now, but popularity of set 4 perhaps will be increased in > : the future because it is standard. Set 1 is small and will be decreased. > : > : -- > : http://ache.pp.ru/ > : > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed May 2 15:14:33 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF6E116A400 for ; Wed, 2 May 2007 15:14:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1C313C44C for ; Wed, 2 May 2007 15:14:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l42Er2hq031670; Wed, 2 May 2007 10:53:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 2 May 2007 10:45:00 -0400 User-Agent: KMail/1.9.6 References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <20070501193146.GD10323@nagual.pp.ru> <20070501.163941.-2001109237.imp@bsdimp.com> In-Reply-To: <20070501.163941.-2001109237.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705021045.01221.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 02 May 2007 10:53:03 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3195/Wed May 2 05:34:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, alfred@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 15:14:33 -0000 On Tuesday 01 May 2007 06:39:41 pm M. Warner Losh wrote: > Andrey, > > Thanks for taking the time to track down all the problems that the > initial commit caused. Thank you also for showing the maturity to > gracefully back out the changes until they can be discussed in more > depth. I know that there's been a lot of emotion expressed over these > changes, and I complement you on keeping your cool during the > discussions. > > I'd like to suggest that people interested in this continue the > discussion in arch@ which is a more appropriate... This post seems to > be the most relevant of the ones from src-commits. If it wasn't obvious from my post, I think that the POSIX putenv(3) is probably the most beneficial going forward. It also doesn't impact the setenv(3) memory fixes, which should also probably go in once someone has reviewed them. > Warner > > In message: <20070501193146.GD10323@nagual.pp.ru> > Andrey Chernov writes: > : On Tue, May 01, 2007 at 12:10:11PM -0400, John Baldwin wrote: > : > Now, that said, apparently some folks on this list CAN'T READ. > : > > : > Linux has the new putenv() algorithm already, so if any software breaks with > : > this, it is _ALREADY_ broken on Linux. Please consider that before ripping > : > ache@ a new one here. As much as BSD wants to feel really important, in > : > truth, most of the software in ports probably runs more often on Linux than > : > on BSD, so I think the chances of non-trivial real-world breakage are fairly > : > small. > : > : And I already tell exactly so about Linux and ports already portable in > : the threads. Perhaps they will hear you better, but the changes in > : question are already backed out and I can't work on them under such > : pressure. In case anyone brave will be found, feel free to restore, and > : then I'll promise my help dealing with all bugs they may cause. > : > : > So with all that said, it seems we have four groups of usage with respect to > : > putenv(3): > : > > : > - give it a stack allocated or otherwise non-persistent buffer (note that > : > string constants are persistent, even if they are read-only) as the first > : > argument. This violates POSIX I guess, and would break on at least Linux and > : > Solaris (judging by Open Solaris's putenv() implementation). > : > : Agreed. > : > : > - pass in a persistent buffer (constant, allocated memory, etc.) and change > : > the contents later expecting that changing the buffer won't change the > : > environment. This breaks Linux and Solaris and POSIX as well. > : > : Agreed. > : > : > - pass in a persistent buffer and don't change it afterwards (at least not > : > until after a later call to putenv or setenv for the same variable). This > : > works for both impls and is probably the vast majority of usage. > : > : Agreed. Most programs don't use the modify-env-on-the-fly feature, but it > : is at the current moment, just because several putenv() implementations > : was hanging around when no one standartized. When POSIX explicitly > : standartize modify-env-on-the-fly feature, more programs will tend to try > : it at time. > : > : > - pass in a persistent buffer and change the contents expecting that it will > : > change the value returned from getenv(). This doesn't work on BSD, but does > : > on Linux + Solaris + POSIX + FreeBSD 7. > : > : Agreed (but not for FreeBSD7 now). > : > : > So we have four groups: 1, 2, 3 (likely the vast majority), and 4. (4) is > : > fixed by this commit, and works on Linux, Solaris, and POSIX. (1 + 2) are > : > broken by this commit, but they also don't work on Linux, Solaris, or POSIX. > : > So the question seems to be, which set is larger, programs that depend on (1 + > : > 2), or programs that depend on (4)? Also, which set is going to get larger > : > as time moves on given Linux's implementation? If you assume (as I do), that > : > most programs fall into (3) anyway, then it really isn't all that important > : > anyway. > : > : Set 3 is larger now, but popularity of set 4 perhaps will be increased in > : the future because it is standard. Set 1 is small and will be decreased. > : > : -- > : http://ache.pp.ru/ > : > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed May 2 15:49:29 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9AFD316A403; Wed, 2 May 2007 15:49:29 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 4064513C48C; Wed, 2 May 2007 15:49:29 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l42FnSBi073983; Wed, 2 May 2007 10:49:28 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l42FnSOC073982; Wed, 2 May 2007 10:49:28 -0500 (CDT) (envelope-from brooks) Date: Wed, 2 May 2007 10:49:28 -0500 From: Brooks Davis To: John Baldwin Message-ID: <20070502154928.GB73631@lor.one-eyed-alien.net> References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <20070501193146.GD10323@nagual.pp.ru> <20070501.163941.-2001109237.imp@bsdimp.com> <200705021045.01221.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <200705021045.01221.jhb@freebsd.org> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 02 May 2007 10:49:28 -0500 (CDT) Cc: arch@freebsd.org, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 15:49:29 -0000 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 02, 2007 at 10:45:00AM -0400, John Baldwin wrote: > On Tuesday 01 May 2007 06:39:41 pm M. Warner Losh wrote: > > Andrey, > >=20 > > Thanks for taking the time to track down all the problems that the > > initial commit caused. Thank you also for showing the maturity to > > gracefully back out the changes until they can be discussed in more > > depth. I know that there's been a lot of emotion expressed over these > > changes, and I complement you on keeping your cool during the > > discussions. > >=20 > > I'd like to suggest that people interested in this continue the > > discussion in arch@ which is a more appropriate... This post seems to > > be the most relevant of the ones from src-commits. >=20 > If it wasn't obvious from my post, I think that the POSIX putenv(3) is > probably the most beneficial going forward. It also doesn't impact the > setenv(3) memory fixes, which should also probably go in once someone > has reviewed them. =46rom your arguments I think this change makes sense. It's probably worth documenting the obviously problems of using this API such as races if used in threaded programs. -- Brooks > > Warner > >=20 > > In message: <20070501193146.GD10323@nagual.pp.ru> > > Andrey Chernov writes: > > : On Tue, May 01, 2007 at 12:10:11PM -0400, John Baldwin wrote: > > : > Now, that said, apparently some folks on this list CAN'T READ. > > : >=20 > > : > Linux has the new putenv() algorithm already, so if any software br= eaks with=20 > > : > this, it is _ALREADY_ broken on Linux. Please consider that before= ripping=20 > > : > ache@ a new one here. As much as BSD wants to feel really importan= t, in=20 > > : > truth, most of the software in ports probably runs more often on Li= nux than=20 > > : > on BSD, so I think the chances of non-trivial real-world breakage a= re fairly=20 > > : > small. > > :=20 > > : And I already tell exactly so about Linux and ports already portable = in=20 > > : the threads. Perhaps they will hear you better, but the changes in=20 > > : question are already backed out and I can't work on them under such= =20 > > : pressure. In case anyone brave will be found, feel free to restore, a= nd=20 > > : then I'll promise my help dealing with all bugs they may cause. > > :=20 > > : > So with all that said, it seems we have four groups of usage with r= espect to=20 > > : > putenv(3): > > : >=20 > > : > - give it a stack allocated or otherwise non-persistent buffer (not= e that=20 > > : > string constants are persistent, even if they are read-only) as the= first=20 > > : > argument. This violates POSIX I guess, and would break on at least= Linux and=20 > > : > Solaris (judging by Open Solaris's putenv() implementation). > > :=20 > > : Agreed. > > :=20 > > : > - pass in a persistent buffer (constant, allocated memory, etc.) an= d change=20 > > : > the contents later expecting that changing the buffer won't change = the=20 > > : > environment. This breaks Linux and Solaris and POSIX as well. > > :=20 > > : Agreed. > > :=20 > > : > - pass in a persistent buffer and don't change it afterwards (at le= ast not=20 > > : > until after a later call to putenv or setenv for the same variable)= =2E This=20 > > : > works for both impls and is probably the vast majority of usage. > > :=20 > > : Agreed. Most programs don't use the modify-env-on-the-fly feature, bu= t it=20 > > : is at the current moment, just because several putenv() implementatio= ns=20 > > : was hanging around when no one standartized. When POSIX explicitly=20 > > : standartize modify-env-on-the-fly feature, more programs will tend to= try=20 > > : it at time. > > :=20 > > : > - pass in a persistent buffer and change the contents expecting tha= t it will=20 > > : > change the value returned from getenv(). This doesn't work on BSD,= but does=20 > > : > on Linux + Solaris + POSIX + FreeBSD 7. > > :=20 > > : Agreed (but not for FreeBSD7 now). > > :=20 > > : > So we have four groups: 1, 2, 3 (likely the vast majority), and 4. = (4) is=20 > > : > fixed by this commit, and works on Linux, Solaris, and POSIX. (1 += 2) are=20 > > : > broken by this commit, but they also don't work on Linux, Solaris, = or POSIX. > > : > So the question seems to be, which set is larger, programs that dep= end on (1 +=20 > > : > 2), or programs that depend on (4)? Also, which set is going to ge= t larger=20 > > : > as time moves on given Linux's implementation? If you assume (as I= do), that=20 > > : > most programs fall into (3) anyway, then it really isn't all that i= mportant=20 > > : > anyway. > > :=20 > > : Set 3 is larger now, but popularity of set 4 perhaps will be increase= d in=20 > > : the future because it is standard. Set 1 is small and will be decreas= ed. > > :=20 > > : --=20 > > : http://ache.pp.ru/ > > :=20 > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >=20 >=20 >=20 >=20 > --=20 > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGOLMHXY6L6fI4GtQRAggBAKDdcAjoQ6QFqveRg2K+HrNg5PV0JwCeNm3e M0POUykD2TrMr4lzBd1LE9A= =Lsub -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- From owner-freebsd-arch@FreeBSD.ORG Wed May 2 16:27:31 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED0A016A411 for ; Wed, 2 May 2007 16:27:31 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 957C613C484 for ; Wed, 2 May 2007 16:27:31 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l42FnSBi073983; Wed, 2 May 2007 10:49:28 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l42FnSOC073982; Wed, 2 May 2007 10:49:28 -0500 (CDT) (envelope-from brooks) Date: Wed, 2 May 2007 10:49:28 -0500 From: Brooks Davis To: John Baldwin Message-ID: <20070502154928.GB73631@lor.one-eyed-alien.net> References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <20070501193146.GD10323@nagual.pp.ru> <20070501.163941.-2001109237.imp@bsdimp.com> <200705021045.01221.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <200705021045.01221.jhb@freebsd.org> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 02 May 2007 10:49:28 -0500 (CDT) Cc: arch@freebsd.org, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 16:27:32 -0000 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 02, 2007 at 10:45:00AM -0400, John Baldwin wrote: > On Tuesday 01 May 2007 06:39:41 pm M. Warner Losh wrote: > > Andrey, > >=20 > > Thanks for taking the time to track down all the problems that the > > initial commit caused. Thank you also for showing the maturity to > > gracefully back out the changes until they can be discussed in more > > depth. I know that there's been a lot of emotion expressed over these > > changes, and I complement you on keeping your cool during the > > discussions. > >=20 > > I'd like to suggest that people interested in this continue the > > discussion in arch@ which is a more appropriate... This post seems to > > be the most relevant of the ones from src-commits. >=20 > If it wasn't obvious from my post, I think that the POSIX putenv(3) is > probably the most beneficial going forward. It also doesn't impact the > setenv(3) memory fixes, which should also probably go in once someone > has reviewed them. =46rom your arguments I think this change makes sense. It's probably worth documenting the obviously problems of using this API such as races if used in threaded programs. -- Brooks > > Warner > >=20 > > In message: <20070501193146.GD10323@nagual.pp.ru> > > Andrey Chernov writes: > > : On Tue, May 01, 2007 at 12:10:11PM -0400, John Baldwin wrote: > > : > Now, that said, apparently some folks on this list CAN'T READ. > > : >=20 > > : > Linux has the new putenv() algorithm already, so if any software br= eaks with=20 > > : > this, it is _ALREADY_ broken on Linux. Please consider that before= ripping=20 > > : > ache@ a new one here. As much as BSD wants to feel really importan= t, in=20 > > : > truth, most of the software in ports probably runs more often on Li= nux than=20 > > : > on BSD, so I think the chances of non-trivial real-world breakage a= re fairly=20 > > : > small. > > :=20 > > : And I already tell exactly so about Linux and ports already portable = in=20 > > : the threads. Perhaps they will hear you better, but the changes in=20 > > : question are already backed out and I can't work on them under such= =20 > > : pressure. In case anyone brave will be found, feel free to restore, a= nd=20 > > : then I'll promise my help dealing with all bugs they may cause. > > :=20 > > : > So with all that said, it seems we have four groups of usage with r= espect to=20 > > : > putenv(3): > > : >=20 > > : > - give it a stack allocated or otherwise non-persistent buffer (not= e that=20 > > : > string constants are persistent, even if they are read-only) as the= first=20 > > : > argument. This violates POSIX I guess, and would break on at least= Linux and=20 > > : > Solaris (judging by Open Solaris's putenv() implementation). > > :=20 > > : Agreed. > > :=20 > > : > - pass in a persistent buffer (constant, allocated memory, etc.) an= d change=20 > > : > the contents later expecting that changing the buffer won't change = the=20 > > : > environment. This breaks Linux and Solaris and POSIX as well. > > :=20 > > : Agreed. > > :=20 > > : > - pass in a persistent buffer and don't change it afterwards (at le= ast not=20 > > : > until after a later call to putenv or setenv for the same variable)= =2E This=20 > > : > works for both impls and is probably the vast majority of usage. > > :=20 > > : Agreed. Most programs don't use the modify-env-on-the-fly feature, bu= t it=20 > > : is at the current moment, just because several putenv() implementatio= ns=20 > > : was hanging around when no one standartized. When POSIX explicitly=20 > > : standartize modify-env-on-the-fly feature, more programs will tend to= try=20 > > : it at time. > > :=20 > > : > - pass in a persistent buffer and change the contents expecting tha= t it will=20 > > : > change the value returned from getenv(). This doesn't work on BSD,= but does=20 > > : > on Linux + Solaris + POSIX + FreeBSD 7. > > :=20 > > : Agreed (but not for FreeBSD7 now). > > :=20 > > : > So we have four groups: 1, 2, 3 (likely the vast majority), and 4. = (4) is=20 > > : > fixed by this commit, and works on Linux, Solaris, and POSIX. (1 += 2) are=20 > > : > broken by this commit, but they also don't work on Linux, Solaris, = or POSIX. > > : > So the question seems to be, which set is larger, programs that dep= end on (1 +=20 > > : > 2), or programs that depend on (4)? Also, which set is going to ge= t larger=20 > > : > as time moves on given Linux's implementation? If you assume (as I= do), that=20 > > : > most programs fall into (3) anyway, then it really isn't all that i= mportant=20 > > : > anyway. > > :=20 > > : Set 3 is larger now, but popularity of set 4 perhaps will be increase= d in=20 > > : the future because it is standard. Set 1 is small and will be decreas= ed. > > :=20 > > : --=20 > > : http://ache.pp.ru/ > > :=20 > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >=20 >=20 >=20 >=20 > --=20 > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGOLMHXY6L6fI4GtQRAggBAKDdcAjoQ6QFqveRg2K+HrNg5PV0JwCeNm3e M0POUykD2TrMr4lzBd1LE9A= =Lsub -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- From owner-freebsd-arch@FreeBSD.ORG Wed May 2 16:29:45 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF9AB16A402; Wed, 2 May 2007 16:29:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 75A3E13C468; Wed, 2 May 2007 16:29:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l42GSAKK027817; Wed, 2 May 2007 10:28:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 May 2007 10:28:22 -0600 (MDT) Message-Id: <20070502.102822.-957833022.imp@bsdimp.com> To: sean-freebsd@farley.org From: "M. Warner Losh" In-Reply-To: <20070501135439.B36275@thor.farley.org> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 02 May 2007 10:28:15 -0600 (MDT) Cc: arch@freebsd.org, current@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 16:29:45 -0000 In message: <20070501135439.B36275@thor.farley.org> "Sean C. Farley" writes: : On Tue, 1 May 2007, Andrey Chernov wrote: : : > All backed out. : > : > Not because I admit they are technically wrong and not because of bug : > reports (I receive nothing). But because I surprisingly meets so : > strong opposition and resistance so lost any desire to continue that. : > : > Anyone who interested in POSIX can dig out what changes and how : > through cvs diffs. : : I am the one writing a replacement for the *env() functions. I have a : BSD (mostly the same except unsetenv() returns an int) version and a : POSIX version. : : Questions for developers to help me proceed: : 1. Would POSIX or BSD be preferred? By POSIX, I do not necessarily mean : completely POSIX. It can be some shade of gray. For example, I : added some checking to putenv() that is not mentioned in the POSIX : spec but makes it closer to setenv() in its errors. : 2. Would a series of stages to move from BSD to POSIX be : acceptable/desired? This is to avoid POSIX from overwhelming people. : 3. How about dropping putenv() altogether? :) putenv() is ugly. My : changes currently prevent setenv() from leaking like a sieve, so the : need for putenv() should not be as necessary. It could also be that : shade of gray where putenv() stayed the way it is (wrapper around : setenv()) while the rest can be POSIX. These are good questions. They should likely be talked about in arch@ Warner From owner-freebsd-arch@FreeBSD.ORG Wed May 2 17:00:06 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7895416A400; Wed, 2 May 2007 17:00:06 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id DADCE13C4AD; Wed, 2 May 2007 17:00:05 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l42GjoZD096337; Wed, 2 May 2007 20:45:50 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l42Gjox6096336; Wed, 2 May 2007 20:45:50 +0400 (MSD) (envelope-from ache) Date: Wed, 2 May 2007 20:45:50 +0400 From: Andrey Chernov To: Brooks Davis Message-ID: <20070502164550.GA96240@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Brooks Davis , John Baldwin , arch@freebsd.org, alfred@freebsd.org, freebsd-arch@freebsd.org References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <20070501193146.GD10323@nagual.pp.ru> <20070501.163941.-2001109237.imp@bsdimp.com> <200705021045.01221.jhb@freebsd.org> <20070502154928.GB73631@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20070502154928.GB73631@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: arch@freebsd.org, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 17:00:06 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 02, 2007 at 10:49:28AM -0500, Brooks Davis wrote: > From your arguments I think this change makes sense. It's probably > worth documenting the obviously problems of using this API such as races > if used in threaded programs. Just for note - POSIX says: "All functions defined by this volume of IEEE Std 1003.1-200x shall be=20 thread-safe, except that the following functions need not be thread-safe." and in the provided list all *env(3) functions are. --=20 http://ache.pp.ru/ --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGOMA+Vg5YK5ZEdN0RAkgWAJ9w80wWIzuzs8QFy5Jp55RffLczkQCcDKon NgLmSqgtZRnrJox8qIiIcBs= =b6wq -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-arch@FreeBSD.ORG Wed May 2 17:00:06 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7895416A400; Wed, 2 May 2007 17:00:06 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id DADCE13C4AD; Wed, 2 May 2007 17:00:05 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l42GjoZD096337; Wed, 2 May 2007 20:45:50 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l42Gjox6096336; Wed, 2 May 2007 20:45:50 +0400 (MSD) (envelope-from ache) Date: Wed, 2 May 2007 20:45:50 +0400 From: Andrey Chernov To: Brooks Davis Message-ID: <20070502164550.GA96240@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Brooks Davis , John Baldwin , arch@freebsd.org, alfred@freebsd.org, freebsd-arch@freebsd.org References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <20070501193146.GD10323@nagual.pp.ru> <20070501.163941.-2001109237.imp@bsdimp.com> <200705021045.01221.jhb@freebsd.org> <20070502154928.GB73631@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20070502154928.GB73631@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: arch@freebsd.org, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 17:00:06 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 02, 2007 at 10:49:28AM -0500, Brooks Davis wrote: > From your arguments I think this change makes sense. It's probably > worth documenting the obviously problems of using this API such as races > if used in threaded programs. Just for note - POSIX says: "All functions defined by this volume of IEEE Std 1003.1-200x shall be=20 thread-safe, except that the following functions need not be thread-safe." and in the provided list all *env(3) functions are. --=20 http://ache.pp.ru/ --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGOMA+Vg5YK5ZEdN0RAkgWAJ9w80wWIzuzs8QFy5Jp55RffLczkQCcDKon NgLmSqgtZRnrJox8qIiIcBs= =b6wq -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-arch@FreeBSD.ORG Wed May 2 17:36:40 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8FDF16A404 for ; Wed, 2 May 2007 17:36:40 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A00F213C484 for ; Wed, 2 May 2007 17:36:40 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l42HaOVF020801; Wed, 2 May 2007 13:36:24 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Wed, 02 May 2007 13:36:24 -0400 (EDT) Date: Wed, 2 May 2007 13:36:24 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20070502.102822.-957833022.imp@bsdimp.com> Message-ID: References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, sean-freebsd@farley.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 17:36:41 -0000 On Wed, 2 May 2007, M. Warner Losh wrote: > In message: <20070501135439.B36275@thor.farley.org> > "Sean C. Farley" writes: > : > : Questions for developers to help me proceed: > : 1. Would POSIX or BSD be preferred? By POSIX, I do not necessarily mean > : completely POSIX. It can be some shade of gray. For example, I > : added some checking to putenv() that is not mentioned in the POSIX > : spec but makes it closer to setenv() in its errors. POSIX is preferred unless there are good reasons to deviate from it for specific interfaces. We are always free to add non-POSIX functions for functionality not defined by the standard. > : 2. Would a series of stages to move from BSD to POSIX be > : acceptable/desired? This is to avoid POSIX from overwhelming people. > : 3. How about dropping putenv() altogether? :) putenv() is ugly. My > : changes currently prevent setenv() from leaking like a sieve, so the > : need for putenv() should not be as necessary. It could also be that > : shade of gray where putenv() stayed the way it is (wrapper around > : setenv()) while the rest can be POSIX. putenv() is in POSIX. It should definitely be implemented. -- DE From owner-freebsd-arch@FreeBSD.ORG Thu May 3 00:26:20 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F073116A402; Thu, 3 May 2007 00:26:20 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 9A39413C459; Thu, 3 May 2007 00:26:20 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from [192.168.1.211] ([192.168.1.211]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l43005di073431; Wed, 2 May 2007 19:00:11 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Wed, 2 May 2007 18:59:28 -0500 (CDT) From: "Sean C. Farley" To: Daniel Eischen In-Reply-To: Message-ID: <20070502183100.P1317@baba.farley.org> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 00:26:21 -0000 On Wed, 2 May 2007, Daniel Eischen wrote: > On Wed, 2 May 2007, M. Warner Losh wrote: > >> In message: <20070501135439.B36275@thor.farley.org> >> "Sean C. Farley" writes: >> >> Questions for developers to help me proceed: >> 1. Would POSIX or BSD be preferred? By POSIX, I do not necessarily >> mean completely POSIX. It can be some shade of gray. For >> example, I added some checking to putenv() that is not mentioned >> in the POSIX spec but makes it closer to setenv() in its errors. > > POSIX is preferred unless there are good reasons to deviate > from it for specific interfaces. We are always free to add > non-POSIX functions for functionality not defined by the > standard. That is good to know. See below for notes about the divergence I made from POSIX. >> 2. Would a series of stages to move from BSD to POSIX be >> acceptable/desired? This is to avoid POSIX from overwhelming >> people. >> 3. How about dropping putenv() altogether? :) putenv() is ugly. >> My changes currently prevent setenv() from leaking like a sieve, >> so the need for putenv() should not be as necessary. It could >> also be that shade of gray where putenv() stayed the way it is >> (wrapper around setenv()) while the rest can be POSIX. > > putenv() is in POSIX. It should definitely be implemented. Here[1] is my POSIX version of the *env() (including putenv()) functions. It also has the leak-avoidance change that occurs with setenv("ab") -> setenv("a") -> setenv("ab"). It is also faster than the current code. Where it diverges from POSIX: 1. putenv() sets errno to EINVAL since it performs checks (NULL pointer, empty string and string without '=') on the string given to it. It makes it a bit more like setenv() in its validation. I found this note[2] that says that providing invalid data to putenv() will result in undefined behavior. I thought that undefined could mean an error is returned. The check is easy to remove. 2. getenv() sets errno to EINVAL and returns NULL if given a bad name to find. setenv() and unsetenv() perform the same check on the name; should not getenv() do the same? The check is easy to remove. Sean 1. http://www.farley.org/freebsd/tmp/setenv-8/POSIX/ 2. http://www.opengroup.org/austin/mailarchives/ag/msg09682.html -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Thu May 3 00:50:41 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 722A816A403 for ; Thu, 3 May 2007 00:50:41 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3601F13C4CA for ; Thu, 3 May 2007 00:50:41 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l430oPuM007809; Wed, 2 May 2007 20:50:25 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Wed, 02 May 2007 20:50:25 -0400 (EDT) Date: Wed, 2 May 2007 20:50:25 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Sean C. Farley" In-Reply-To: <20070502183100.P1317@baba.farley.org> Message-ID: References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 00:50:41 -0000 On Wed, 2 May 2007, Sean C. Farley wrote: > > Here[1] is my POSIX version of the *env() (including putenv()) > functions. It also has the leak-avoidance change that occurs with > setenv("ab") -> setenv("a") -> setenv("ab"). It is also faster than the > current code. > > Where it diverges from POSIX: > 1. putenv() sets errno to EINVAL since it performs checks (NULL pointer, > empty string and string without '=') on the string given to it. It > makes it a bit more like setenv() in its validation. I found this > note[2] that says that providing invalid data to putenv() will result > in undefined behavior. I thought that undefined could mean an error > is returned. The check is easy to remove. I think that is fine as it falls under "undefined behavior", and the function is already defined as returning an error code. > 2. getenv() sets errno to EINVAL and returns NULL if given a bad name to > find. setenv() and unsetenv() perform the same check on the name; > should not getenv() do the same? The check is easy to remove. I don't think getenv() should set errno. The fact that it returns NULL is sufficient and POSIX doesn't define any errors for it. -- DE From owner-freebsd-arch@FreeBSD.ORG Thu May 3 04:08:29 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9778416A401; Thu, 3 May 2007 04:08:29 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 61CDC13C448; Thu, 3 May 2007 04:08:29 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l4349w7u076550; Wed, 2 May 2007 23:09:59 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Wed, 2 May 2007 23:08:18 -0500 (CDT) From: "Sean C. Farley" To: Daniel Eischen In-Reply-To: Message-ID: <20070502230413.Y30614@thor.farley.org> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 04:08:29 -0000 On Wed, 2 May 2007, Daniel Eischen wrote: > On Wed, 2 May 2007, Sean C. Farley wrote: >> 2. getenv() sets errno to EINVAL and returns NULL if given a bad name >> to find. setenv() and unsetenv() perform the same check on the >> name; should not getenv() do the same? The check is easy to >> remove. > > I don't think getenv() should set errno. The fact that it > returns NULL is sufficient and POSIX doesn't define any errors > for it. Fixed for errno. Also, no value is appropriate for errno when the name does not exist. How about the feature that getenv() returns a NULL for a bad name instead of allowing a core dump? Is that acceptable? Sean -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Thu May 3 04:23:06 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3FEE16A404 for ; Thu, 3 May 2007 04:23:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9862E13C45B for ; Thu, 3 May 2007 04:23:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l434Mq0A005680; Thu, 3 May 2007 00:22:52 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Thu, 03 May 2007 00:22:52 -0400 (EDT) Date: Thu, 3 May 2007 00:22:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Sean C. Farley" In-Reply-To: <20070502230413.Y30614@thor.farley.org> Message-ID: References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 04:23:06 -0000 On Wed, 2 May 2007, Sean C. Farley wrote: > On Wed, 2 May 2007, Daniel Eischen wrote: > >> On Wed, 2 May 2007, Sean C. Farley wrote: > > > >>> 2. getenv() sets errno to EINVAL and returns NULL if given a bad name >>> to find. setenv() and unsetenv() perform the same check on the >>> name; should not getenv() do the same? The check is easy to >>> remove. >> >> I don't think getenv() should set errno. The fact that it >> returns NULL is sufficient and POSIX doesn't define any errors >> for it. > > Fixed for errno. Also, no value is appropriate for errno when the name > does not exist. How about the feature that getenv() returns a NULL for > a bad name instead of allowing a core dump? Is that acceptable? I thought that is what I said above ;-) POSIX says this about getenv(): Upon successful completion, getenv() shall return a pointer to a string containing the value for the specified name. If the specified name cannot be found in the environment of the calling process, a null pointer shall be returned. I'd argue that a bad name is the same thing as if it were a good name but couldn't be found. You really don't want a core dump unless you have to jump through too many hoops to prevent one. As long as the name is a valid pointer to a valid string, then you should just search the environment for the string. It looks like the only character not allowed is '='. -- DE From owner-freebsd-arch@FreeBSD.ORG Thu May 3 16:04:03 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BC2C16A406; Thu, 3 May 2007 16:04:03 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 90C3A13C487; Thu, 3 May 2007 16:04:02 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l43G3piO016023; Thu, 3 May 2007 20:03:51 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l43G3p2N016021; Thu, 3 May 2007 20:03:51 +0400 (MSD) (envelope-from ache) Date: Thu, 3 May 2007 20:03:51 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070503160351.GA15008@nagual.pp.ru> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070502230413.Y30614@thor.farley.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 16:04:03 -0000 On Wed, May 02, 2007 at 11:08:18PM -0500, Sean C. Farley wrote: > On Wed, 2 May 2007, Daniel Eischen wrote: > > > On Wed, 2 May 2007, Sean C. Farley wrote: > > > > >> 2. getenv() sets errno to EINVAL and returns NULL if given a bad name > >> to find. setenv() and unsetenv() perform the same check on the > >> name; should not getenv() do the same? The check is easy to > >> remove. > > > > I don't think getenv() should set errno. The fact that it > > returns NULL is sufficient and POSIX doesn't define any errors > > for it. > > Fixed for errno. Also, no value is appropriate for errno when the name > does not exist. How about the feature that getenv() returns a NULL for > a bad name instead of allowing a core dump? Is that acceptable? Speaking about POSIXed error checking in *env() you can look at my backed out implemetation (via cvs diff), you may find it useful for you. -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Fri May 4 15:58:38 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5822616A403; Fri, 4 May 2007 15:58:38 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id B9C8613C46A; Fri, 4 May 2007 15:58:37 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id l44FwYqL022643; Fri, 4 May 2007 18:58:34 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l44FwYcv017427; Fri, 4 May 2007 18:58:34 +0300 Received: from [192.168.136.22] (ppp124-213.adsl.forthnet.gr [193.92.231.213]) by MX-IN-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l44FwQv6016853; Fri, 4 May 2007 18:58:26 +0300 Authentication-Results: MX-IN-04.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <463B581E.6070804@aueb.gr> Date: Fri, 04 May 2007 18:58:22 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: arch@FreeBSD.org References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> <4627A6C3.2070409@aueb.gr> <20070419212253.L2913@fledge.watson.org> <4627E311.6080500@aueb.gr> In-Reply-To: <4627E311.6080500@aueb.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: re@FreeBSD.org, Poul-Henning Kamp , Robert Watson Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 15:58:38 -0000 I've put a proposed new version of acct.h at http://www.spinellis.gr/FreeBSD/acct.h Following earlier discussion and comments, here is its design rationale. [In square brackets is the identifier of people whose comments are addressed by each design decision.] On modern processors the various time values were 0, because many commands took less than 1/64s to execute [bde]. Now time values are stored with microsecond precision as float numbers.(I've written code that allows the kernel to write them without any floating point operations.) Users often keep accounting data for many years back; we should offer backwards compatibility [rwatson, sam]. Binary compatibility of legacy accounting data will be documented (in acct.h and acct(5)) and maintained. I will modify sa(8) and lastcomm(1) to read both acctv1 and acctv2 accounting records. Backwards compatibility of the sa(8)-generated compacted accounting files can be maintained by continuing to store in them time in AHZV1 units. Third-party programs reading accounting data may get confused by the new format [dds]. I intentionally broke source-code compatibility by renaming "struct acct" to "struct acctv1", so that other programs reading accounting records will not accidentally try to read new records into the old structure. Files containing records of acctv1 and/or acctv2 structures should be readable backwards and forwards. (lastcomm(1) requires this capability [dds].) A length field exists at both ends. At the heading-end a zero byte indicates a post v1 version. At the trailing-end an ANVER flag indicates the same. Alignment differences might have ac_flag to be in different relative locations from the end of the file in the two versions [rwatson]. To guarantee that the location of ac_flag at the end of the acctv2 record remains in the same location from the end as on the legacy acctv1 record, I used a union to force the same alignment. Although an anonymous union would result in clearer code, I did not use it, because this is a gcc extension. The field ac_tty is nowadays useless and should be replaced with a credential identifier [phk]. A credential identifier has not been added, because this could be inferred from a (suitably updated) wtmp. The current structure provides a clean upgrade path, if we wish to add such a feature in the future. Diomidis - dds@ From owner-freebsd-arch@FreeBSD.ORG Fri May 4 18:22:01 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7B9C16A403; Fri, 4 May 2007 18:22:01 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id A5AAA13C448; Fri, 4 May 2007 18:22:01 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l44INUOg016911; Fri, 4 May 2007 13:23:31 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Fri, 4 May 2007 13:21:50 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070503160351.GA15008@nagual.pp.ru> Message-ID: <20070504085905.J39482@thor.farley.org> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 18:22:02 -0000 On Thu, 3 May 2007, Andrey Chernov wrote: > On Wed, May 02, 2007 at 11:08:18PM -0500, Sean C. Farley wrote: >> On Wed, 2 May 2007, Daniel Eischen wrote: >> >>> On Wed, 2 May 2007, Sean C. Farley wrote: >> >> >> >>>> 2. getenv() sets errno to EINVAL and returns NULL if given a bad >>>> name to find. setenv() and unsetenv() perform the same check on >>>> the name; should not getenv() do the same? The check is easy to >>>> remove. >>> >>> I don't think getenv() should set errno. The fact that it >>> returns NULL is sufficient and POSIX doesn't define any errors >>> for it. >> >> Fixed for errno. Also, no value is appropriate for errno when the >> name does not exist. How about the feature that getenv() returns a >> NULL for a bad name instead of allowing a core dump? Is that >> acceptable? > > Speaking about POSIXed error checking in *env() you can look at my > backed out implemetation (via cvs diff), you may find it useful for > you. I believe I check all that you did in your changes. Mine looks a little different since some checks were combined for speed (i.e., __strleneq()). The only other question I have is about leading whitespace in the name passed to *env(): 1. Should it be removed up to the first non-whitespace character? 2. Treated as part of the variable name. Is this allowed by the specification? 3. Return errno = EINVAL. getenv() would just return NULL. I am leaning towards #2 since it may be desired by a developer. If "FOO BAR" is valid, why not " FOOBAR"? I see that /usr/bin/env currently allows it. If #2 is good, then I think my code is functionally complete. This is of course not counting any hiding bugs. :) Sean -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Fri May 4 18:38:16 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBB7216A400; Fri, 4 May 2007 18:38:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id ABA9013C458; Fri, 4 May 2007 18:38:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.2]) by phk.freebsd.dk (Postfix) with ESMTP id A348117382; Fri, 4 May 2007 18:38:14 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l44Ic79e019236; Fri, 4 May 2007 18:38:09 GMT (envelope-from phk@critter.freebsd.dk) To: Diomidis Spinellis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 May 2007 18:58:22 +0300." <463B581E.6070804@aueb.gr> Date: Fri, 04 May 2007 18:38:07 +0000 Message-ID: <19235.1178303887@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@FreeBSD.org, Robert Watson , re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 18:38:17 -0000 In message <463B581E.6070804@aueb.gr>, Diomidis Spinellis writes: >On modern processors the various time values were 0, because many >commands took less than 1/64s to execute [bde]. Now time values are >stored with microsecond precision as float numbers.(I've written code >that allows the kernel to write them without any floating point >operations.) Why on earth introduce another time format ? Please use a standard time format please. -- 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. From owner-freebsd-arch@FreeBSD.ORG Fri May 4 21:33:25 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3606E16A401; Fri, 4 May 2007 21:33:25 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id A943313C459; Fri, 4 May 2007 21:33:24 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l44LXDL7034777; Sat, 5 May 2007 01:33:13 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l44LXDJ0034776; Sat, 5 May 2007 01:33:13 +0400 (MSD) (envelope-from ache) Date: Sat, 5 May 2007 01:33:12 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070504213312.GA33163@nagual.pp.ru> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070504085905.J39482@thor.farley.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 21:33:25 -0000 On Fri, May 04, 2007 at 01:21:50PM -0500, Sean C. Farley wrote: > I believe I check all that you did in your changes. Mine looks a little > different since some checks were combined for speed (i.e., > __strleneq()). Looking at http://www.farley.org/freebsd/tmp/setenv-8/POSIX/sysenv.c __strleneq() - "Inline strlen() for performance." - no performance gain such way but lost, because strlen() already auto-inlined with gcc -O2 in much better assembler form: repnz scasb So there is no point to call __strleneq(..., false); too instead of just strlen() (which will be auto-inlined by gcc) directly. Currently __clean_env is unused. Why don't #if 0 it? I think "Check for malformed name" should be before "Initialize environment" - with malformed arg complex environment mallocing/copying initialization ever not needed. In __build_env() when strdup() returns NULL, you better free all previous strdups in that loop and envVars too before returning (-1) Why you use strstr(envVars[envNdx].name, "="); instead of strchr(envVars[envNdx].name, '='); ? In theory strchr() can be gcc-inlined or assembler-implemented with more probability than strstr() (currently both are not inlined at i386). __rebuild_environ() needs to use realloc() instead of reallocf() because realloc() not touch original pointer/content when fails. I.e. _whole_ "environ" will not be lost in case can't be enlarged. Something like that: TempEnvironSize = newEnvSize * 2; TempEnviron = realloc(environ, sizeof (*environ) * (TempEnvironSize + 1)); if (TempEnviron == NULL) return (-1); environ = TempEnviron; environSize = TempEnvironSize; > The only other question I have is about leading whitespace in the name > passed to *env(): > 1. Should it be removed up to the first non-whitespace character? > 2. Treated as part of the variable name. Is this allowed by the > specification? > 3. Return errno = EINVAL. getenv() would just return NULL. POSIX says about names: 1) "names shall not contain the character '='" and "points to an empty string". 2) "Other characters may be permitted by an implementation; applications shall tolerate the presence of such names." So I see no point to treat ' ' some special way. -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Fri May 4 22:26:43 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6D8C16A400; Fri, 4 May 2007 22:26:43 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4806013C45E; Fri, 4 May 2007 22:26:42 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l44MQXAi035598; Sat, 5 May 2007 02:26:33 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l44MQXL1035596; Sat, 5 May 2007 02:26:33 +0400 (MSD) (envelope-from ache) Date: Sat, 5 May 2007 02:26:32 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070504222632.GA35447@nagual.pp.ru> References: <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070504213312.GA33163@nagual.pp.ru> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 22:26:43 -0000 On Sat, May 05, 2007 at 01:33:12AM +0400, Andrey Chernov wrote: > On Fri, May 04, 2007 at 01:21:50PM -0500, Sean C. Farley wrote: > > I believe I check all that you did in your changes. Mine looks a little > > different since some checks were combined for speed (i.e., > > __strleneq()). > > Looking at > http://www.farley.org/freebsd/tmp/setenv-8/POSIX/sysenv.c It seems putenv("a=b"); ... putenv("a=c"); can be optimized a bit more. Currently you always realloc and rebuild_environ on any putenv call. But envVars[envNdx].active = false; if (envVars[envNdx].putenv) __remove_putenv(envNdx); in putenv() can be just changed to: if (envVars[envNdx].putenv) { envVars[envNdx].name = string; return (0); } envVars[envNdx].active = false; (unless I not miss something). -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Fri May 4 22:50:01 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D1E216A402; Fri, 4 May 2007 22:50:01 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 788C613C457; Fri, 4 May 2007 22:50:00 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id l44Mnwt0003750; Sat, 5 May 2007 01:49:58 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l44MnvCZ030980; Sat, 5 May 2007 01:49:57 +0300 Received: from [192.168.136.22] (ppp124-213.adsl.forthnet.gr [193.92.231.213]) by MX-IN-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l44Mnupt028970; Sat, 5 May 2007 01:49:56 +0300 Authentication-Results: MX-IN-01.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <463BB88F.4020804@aueb.gr> Date: Sat, 05 May 2007 01:49:51 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Poul-Henning Kamp References: <19235.1178303887@critter.freebsd.dk> In-Reply-To: <19235.1178303887@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Robert Watson , re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 22:50:01 -0000 Poul-Henning Kamp wrote: > In message <463B581E.6070804@aueb.gr>, Diomidis Spinellis writes: > >> On modern processors the various time values were 0, because many >> commands took less than 1/64s to execute [bde]. Now time values are >> stored with microsecond precision as float numbers.(I've written code >> that allows the kernel to write them without any floating point >> operations.) > > Why on earth introduce another time format ? > > Please use a standard time format please. If we use struct timeval for the three time values the structure size increases considerably (especially on an amd64). Here are some numbers: i386 Old size=48 New size=64 New size with timeval=76 amd64 Old size=56 New size=72 New size timeval=112 On a busy system this increase can be more than 10GB / month. Is there some other standard time format I've missed? Diomidis From owner-freebsd-arch@FreeBSD.ORG Fri May 4 23:01:13 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8536216A402; Fri, 4 May 2007 23:01:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 44ABE13C46A; Fri, 4 May 2007 23:01:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.2]) by phk.freebsd.dk (Postfix) with ESMTP id 4834517382; Fri, 4 May 2007 23:01:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l44N17lb021182; Fri, 4 May 2007 23:01:07 GMT (envelope-from phk@critter.freebsd.dk) To: Diomidis Spinellis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 05 May 2007 01:49:51 +0300." <463BB88F.4020804@aueb.gr> Date: Fri, 04 May 2007 23:01:07 +0000 Message-ID: <21181.1178319667@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@FreeBSD.org, Robert Watson , re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 23:01:13 -0000 In message <463BB88F.4020804@aueb.gr>, Diomidis Spinellis writes: >Poul-Henning Kamp wrote: >> In message <463B581E.6070804@aueb.gr>, Diomidis Spinellis writes: >> >>> On modern processors the various time values were 0, because many >>> commands took less than 1/64s to execute [bde]. Now time values are >>> stored with microsecond precision as float numbers.(I've written code >>> that allows the kernel to write them without any floating point >>> operations.) >> >> Why on earth introduce another time format ? >> >> Please use a standard time format please. > >If we use struct timeval for the three time values the structure size >increases considerably (especially on an amd64). Here are some numbers: > >i386 >Old size=48 >New size=64 >New size with timeval=76 that is a good argument. -- 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. From owner-freebsd-arch@FreeBSD.ORG Fri May 4 23:05:46 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C23D16A403; Fri, 4 May 2007 23:05:46 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 833F613C44C; Fri, 4 May 2007 23:05:45 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l44N5Zd6036158; Sat, 5 May 2007 03:05:35 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l44N5YUn036157; Sat, 5 May 2007 03:05:34 +0400 (MSD) (envelope-from ache) Date: Sat, 5 May 2007 03:05:34 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070504230533.GA36089@nagual.pp.ru> References: <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504222632.GA35447@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070504222632.GA35447@nagual.pp.ru> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2007 23:05:46 -0000 On Sat, May 05, 2007 at 02:26:32AM +0400, Andrey Chernov wrote: > in putenv() can be just changed to: > > if (envVars[envNdx].putenv) { > envVars[envNdx].name = string; > return (0); > } > envVars[envNdx].active = false; > > (unless I not miss something). Oops. I forget rebuild. New variant: if (envVars[envNdx].putenv) { envVars[envNdx].name = string; return (__rebuild_environ(envActive)); } envVars[envNdx].active = false; -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Sat May 5 15:17:53 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF63016A401 for ; Sat, 5 May 2007 15:17:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 53FE713C45B for ; Sat, 5 May 2007 15:17:53 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [81.191.58.152] (account mc467741@c2i.net HELO [192.168.1.123]) by mailfe09.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 312461662 for freebsd-arch@freebsd.org; Sat, 05 May 2007 16:17:50 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 5 May 2007 16:17:34 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705051617.34162.hselasky@c2i.net> Subject: Missing LIST_PREV() ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2007 15:17:53 -0000 Hi, Why should LISTs only be forward traversable? The following piece of code make lists backward traversable: /sys/sys/queue.h: +#define LIST_PREV(head,elm,field) \ + (((elm) == LIST_FIRST(head)) ? ((__typeof(elm))0) : \ + ((__typeof(elm))(((uint8_t *)((elm)->field.le_prev)) - \ + ((uint8_t *)&LIST_NEXT((__typeof(elm))0,field))))) Any comments? --HPS From owner-freebsd-arch@FreeBSD.ORG Sat May 5 20:56:34 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6075516A400; Sat, 5 May 2007 20:56:34 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2CF13C44B; Sat, 5 May 2007 20:56:33 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l45Kw38O039428; Sat, 5 May 2007 15:58:03 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Sat, 5 May 2007 15:56:21 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070504213312.GA33163@nagual.pp.ru> Message-ID: <20070504174657.D1343@thor.farley.org> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2007 20:56:34 -0000 On Sat, 5 May 2007, Andrey Chernov wrote: > On Fri, May 04, 2007 at 01:21:50PM -0500, Sean C. Farley wrote: >> I believe I check all that you did in your changes. Mine looks a >> little different since some checks were combined for speed (i.e., >> __strleneq()). > > Looking at > http://www.farley.org/freebsd/tmp/setenv-8/POSIX/sysenv.c > > __strleneq() - "Inline strlen() for performance." - no performance > gain such way but lost, because strlen() already auto-inlined with gcc > -O2 in much better assembler form: > repnz > scasb > So there is no point to call __strleneq(..., false); too instead of > just strlen() (which will be auto-inlined by gcc) directly. Interestingly, gcc 3.4.6 on -STABLE does not do such a great job even with -minline-all-stringops. I do have CPUTYPE?=pentium4 in /etc/make.conf. Maybe this is only an issue with i386 similar to what you mention below? > Currently __clean_env is unused. Why don't #if 0 it? It currently is used when the library is unloaded. My hope was for dmalloc to stop reporting leaks by cleaning up afterwards. It is still good for catching my mistakes. It can be #if 0'd out when everything else is good. Actually, I will keep it, so it can be used if __build_env() fails on the strdup(). > I think "Check for malformed name" should be before "Initialize > environment" - with malformed arg complex environment > mallocing/copying initialization ever not needed. I reversed the checks to be before the initialization. > In __build_env() when strdup() returns NULL, you better free all previous > strdups in that loop and envVars too before returning (-1) Calling __clean_env() now to clean up everything upon failure. > Why you use strstr(envVars[envNdx].name, "="); instead of > strchr(envVars[envNdx].name, '='); ? In theory strchr() can be > gcc-inlined or assembler-implemented with more probability than > strstr() (currently both are not inlined at i386). I did not think about gcc optimizations. I fixed it to use strchr(). > __rebuild_environ() needs to use realloc() instead of reallocf() > because realloc() not touch original pointer/content when fails. I.e. > _whole_ "environ" will not be lost in case can't be enlarged. Something > like that: > > TempEnvironSize = newEnvSize * 2; > TempEnviron = realloc(environ, sizeof (*environ) * > (TempEnvironSize + 1)); > if (TempEnviron == NULL) > return (-1); > environ = TempEnviron; > environSize = TempEnvironSize; True enough. I had thought about that awhile ago but had forgotten about going back to fix the reallocf() calls. >> The only other question I have is about leading whitespace in the >> name passed to *env(): >> 1. Should it be removed up to the first non-whitespace character? >> 2. Treated as part of the variable name. Is this allowed by the >> specification? >> 3. Return errno = EINVAL. getenv() would just return NULL. > > POSIX says about names: > 1) "names shall not contain the character '='" and "points to an empty > string". > 2) "Other characters may be permitted by an implementation; > applications shall tolerate the presence of such names." > So I see no point to treat ' ' some special way. Agreed. Concerning the optimization of putenv() you mentioned in a later e-mail, I fixed that too. It is much faster. I also placed my regression tests (not all work with the old code) in the same directory[1] as the latest code. One oddity I noticed: /bin/sh as the shell runs the timings much slower than either /bin/tcsh or /usr/local/bin/zsh. This is regardless if its my code or the old code. Sean 1. http://www.farley.org/freebsd/tmp/setenv-8/POSIX/ -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Sat May 5 21:32:14 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E40A16A403; Sat, 5 May 2007 21:32:14 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0F07913C459; Sat, 5 May 2007 21:32:13 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l45LW3KJ049989; Sun, 6 May 2007 01:32:03 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l45LW3xY049988; Sun, 6 May 2007 01:32:03 +0400 (MSD) (envelope-from ache) Date: Sun, 6 May 2007 01:32:02 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070505213202.GA49925@nagual.pp.ru> References: <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070504174657.D1343@thor.farley.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2007 21:32:14 -0000 On Sat, May 05, 2007 at 03:56:21PM -0500, Sean C. Farley wrote: > Interestingly, gcc 3.4.6 on -STABLE does not do such a great job even > with -minline-all-stringops. I do have CPUTYPE?=pentium4 in > /etc/make.conf. Maybe this is only an issue with i386 similar to what > you mention below? Even "cc -O" do that, without any flags, see live example below: a.c: #include #include #include main() { printf("%d\n", strlen(getenv("HOME"))); } cc -O -S a.c cat a.s .file "a.c" .section .rodata.str1.1,"aMS",@progbits,1 .LC0: .string "HOME" .LC1: .string "%d\n" .text .p2align 2,,3 .globl main .type main, @function main: pushl %ebp movl %esp, %ebp pushl %edi subl $4, %esp andl $-16, %esp subl $28, %esp pushl $.LC0 call getenv addl $8, %esp movl %eax, %edi cld movl $-1, %ecx movb $0, %al repnz scasb notl %ecx decl %ecx pushl %ecx pushl $.LC1 call printf movl -4(%ebp), %edi leave ret .size main, .-main .ident "GCC: (GNU) 3.4.6 [FreeBSD] 20060825" -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Sat May 5 21:48:56 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 855DB16A40B; Sat, 5 May 2007 21:48:56 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 4654C13C4AE; Sat, 5 May 2007 21:48:55 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l45LoQHY040058; Sat, 5 May 2007 16:50:26 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Sat, 5 May 2007 16:48:44 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070505213202.GA49925@nagual.pp.ru> Message-ID: <20070505163707.J6670@thor.farley.org> References: <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2007 21:48:56 -0000 On Sun, 6 May 2007, Andrey Chernov wrote: > On Sat, May 05, 2007 at 03:56:21PM -0500, Sean C. Farley wrote: >> Interestingly, gcc 3.4.6 on -STABLE does not do such a great job even >> with -minline-all-stringops. I do have CPUTYPE?=pentium4 in >> /etc/make.conf. Maybe this is only an issue with i386 similar to what >> you mention below? > > Even "cc -O" do that, without any flags, see live example below: I have the same assembly output. Inlined __strleneq() ends up being faster on my system than GCC's strlen() when I changed all calls where checkEquals equaled false. I believe you that it should be faster with GCC's version, but it is not ending up that way on my Athlon XP and Pentium 4 systems running FreeBSD 6.2. There is now a sysenv-strlen.c that I tested the timings.c program in regressions/environment directory. It keeps showing __strleneq() to be faster. Sean -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Sat May 5 22:11:39 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21AFA16A408; Sat, 5 May 2007 22:11:39 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 49C5313C4EC; Sat, 5 May 2007 22:11:36 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l45MBPZ6050534; Sun, 6 May 2007 02:11:25 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l45MBP2b050533; Sun, 6 May 2007 02:11:25 +0400 (MSD) (envelope-from ache) Date: Sun, 6 May 2007 02:11:25 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070505221125.GA50439@nagual.pp.ru> References: <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070505163707.J6670@thor.farley.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2007 22:11:39 -0000 On Sat, May 05, 2007 at 04:48:44PM -0500, Sean C. Farley wrote: > I have the same assembly output. Inlined __strleneq() ends up being > faster on my system than GCC's strlen() when I changed all calls where > checkEquals equaled false. I believe you that it should be faster with > GCC's version, but it is not ending up that way on my Athlon XP and > Pentium 4 systems running FreeBSD 6.2. > > There is now a sysenv-strlen.c that I tested the timings.c program in > regressions/environment directory. It keeps showing __strleneq() to be > faster. I wonder how it possible. Your after "if" variant becomes .L13: incl %eax cmpb $0, (%eax) jne .L13 which should be slower in general than gcc ones. Could you please run some test for just this two functions (without all other stuff): strlen() (gcc -O) and inlined __strleneq() for some array of different-size strings? -- http://ache.pp.ru/