cvs commit: src/usr.sbin/sysinstall main.c

John Baldwin jhb at freebsd.org
Wed May 2 15:14:33 UTC 2007


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 at nagual.pp.ru>
>             Andrey Chernov <ache at 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.
> : > 
> : > 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 



-- 
John Baldwin


More information about the freebsd-arch mailing list