Date: Sat, 9 Nov 2002 17:38:33 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: "M. Warner Losh" <imp@bsdimp.com>, ataraxia@cox.net, current@FreeBSD.ORG Subject: Re: [PATCH] note the __sF change in src/UPDATING Message-ID: <200211091738.33940.dfr@nlsystems.com> In-Reply-To: <Pine.GSO.4.10.10211091114160.15854-100000@pcnet1.pcnet.com> References: <Pine.GSO.4.10.10211091114160.15854-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 09 November 2002 4:28 pm, Daniel Eischen wrote: > On Sat, 9 Nov 2002, Doug Rabson wrote: > > On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: > > > On Fri, 8 Nov 2002, M. Warner Losh wrote: > > > > This is not a fly in the pointment, but rather a major > > > > incompatibility that makes it impossible to have a reasonable > > > > mix. > > > > > > If it's really a hassle for folks, then just provide the > > > optional compatability hack and make them rebuild libc. > > > Or provide a pre-built version that doesn't get installed > > > by default. > > > > So what you are saying, basically, is that we should ship a > > release, for the first time ever, which can't run old binaries. > > Sorry, that isn't acceptable. The correct and robust way of doing > > things is to stop creating binaries (in both 4.x and 5.x) that > > reference __sF, then wait a full release cycle for the change to > > propagate. We can then remove the symbol in 6.x. > > If you put an optional compatibility hack in libc, then folks > can still use it, plus they will be informed that it is going > away at some point. I don't think removing it from <stdio.h> > is good enough. Unless there's a way of putting out an error > message at run-time, we need some other way of being a little > bit of a nuisance. I don't see the need for this. We aren't supporting the original broken=20 API (i.e. __sF in stdio.h). We do need to support the broken ABI for=20 another release cycle otherwise we break everyone who tries to upgrade=20 from 4.x to 5.x, which is a bad thing. > > > In general, its a very poor idea to simply remove a feature that > > was supported in the last release of a package. The normal route is > > to deprecate (but still support) the feature in one release and > > remove it in the next. > > Do kld's from 4.x work on -current? Just curious -- I don't really > know. The kernel ABI is hopeless. It changes almost daily :-(. At one time, I=20 thought I could change this but these days, I don't think anyone except=20 me cares about having a stable ABI in the kernel. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211091738.33940.dfr>