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