From owner-freebsd-current Fri Nov 8 9:17:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B085437B401 for ; Fri, 8 Nov 2002 09:17:13 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D34843E42 for ; Fri, 8 Nov 2002 09:17:13 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id gA8HH1gr029307; Fri, 8 Nov 2002 12:17:01 -0500 (EST) Date: Fri, 8 Nov 2002 12:17:00 -0500 (EST) From: Daniel Eischen To: "M. Warner Losh" Cc: ataraxia@cox.net, current@FreeBSD.ORG Subject: Re: [PATCH] note the __sF change in src/UPDATING In-Reply-To: <20021108.092732.124899267.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Nov 2002, M. Warner Losh wrote: > In message: <200211081149.gA8BnGF5073259@arkadia.nv.cox.net> > Ray Kohler writes: > : > From owner-freebsd-current@FreeBSD.ORG Fri Nov 8 02:45:04 2002 > : > Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST) > : > To: current@FreeBSD.ORG > : > Subject: Re: [PATCH] note the __sF change in src/UPDATING > : > From: "M. Warner Losh" > : > > : > In message: <200211072337.gA7NbK1m082069@arkadia.nv.cox.net> > : > Ray Kohler writes: > : > : Hear hear, I agree. There's no need to expose what ought to be > : > : "private" data to the world, especially when we can get the additional > : > : benefit here of letting us play with the implementation. > : > > : > -current already does this. The problem is that we're trying to shoot > : > the bad access in the head, and that is what is screwing people. So > : > the problem isn't that we're trying to export private data to the > : > world. Quite the contrary, we're trying to eliminate it and having > : > growing pains. > : > : Exactly. That's why I'm arguing against putting __sF back (or > : adopting equally crapulent measures). Growing pains are a necessary evil. > : (I also agree that we probably ought to staticize any other things of > : this nature while we're at it and get the pain over with.) > > Yes, but this is too painful. If we were going to do this, the time > for the pain was 6-9 months ago, not just before the release. All the ports are going to be rebuilt for the release anyways, so this doesn't affect fresh installs, correct? It is only a problem when mixing older 4.x and 5.0 libraries/binaries with __sF-free libc (if I understand things correctly). This is 5.0; it is a major release and there will be some flies in the ointment. I say bite the bullet now -- don't wait. If we want to provide an optional compatability hack to libc so that folks can compile it with __sF support, then I think that is better than leaving __sF in the release, perhaps with a mktemp(3)-like warning if possible (?). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message