Date: Wed, 2 May 2007 10:49:28 -0500 From: Brooks Davis <brooks@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c Message-ID: <20070502154928.GB73631@lor.one-eyed-alien.net> In-Reply-To: <200705021045.01221.jhb@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ache@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070502154928.GB73631>