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

[Brooks Davis]

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

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.

-- Brooks

> > 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
> _______________________________________________
> 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"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20070502/f39a13de/attachment-0001.pgp