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/ :