Date: Fri, 1 Nov 2002 08:35:58 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: Alfred Perlstein <alfred@FreeBSD.ORG>, Peter Wemm <peter@wemm.org>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio findfp.c Message-ID: <20021031213557.GG6446@gsmx07.alcatel.com.au> In-Reply-To: <20021031220322.Y9371-100000@gamplex.bde.org> References: <20021031095115.GW24139@elvis.mu.org> <20021031220322.Y9371-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Oct-31 22:15:51 +1100, Bruce Evans <bde@zeta.org.au> wrote: >On Thu, 31 Oct 2002, Alfred Perlstein wrote: > >> * Bruce Evans <bde@zeta.org.au> [021031 01:25] wrote: >> > "Fixing" signal handling broke even more things here. Old kernels can no >> > longer run many new binaries because new binaries use the new sigaction() >> > syscall just to select the type of signal context passed to signal handlers, >> > most of which don't care about the type. If someone really cared about this, they could probably write code for all the sigXXX(3) functions that use sigXXX(2) interfaces to check for SIGSYS/ENOSYS and revert to the osigXXX(2) interfaces. This would probably handle most simple programs. (Of course, safely detecting SIGSYS whilst trying to install a handler for SIGSYS makes the task more interesting). >> While this is true and you are correct, I don't see how this >> reflects negatively on the decision to statisize __sF. > >It reflects positively (unfortunately). Almost everything is incompatible >unless they were compiled at the same time. OTOH, recompiling all >applications to make them stop using __sF makes them not work on yesterday's >kernel. Maybe I missed something but which parts of __sF rely on kernel interfaces? You mightn't be able to use yesterdays libc, but you should be able to use yesterday's kernel (for a 'yesterday' since about September 1999). I agree that this sort of API breakage is a nuisance but I don't see how we can make any progress if we insist that any application compiled on FreeBSD 1.0 will run on today's system and any application compiled today will run on a FreeBSD 1.0 system. Overall, I think we do fairly well. There have been three major API breakages that I can think of: a.out -> ELF, the sigset_t changes and these __sF changes. ELF support was added sometime around 2.2.5, the 'standard' format changed from a.out to ELF in 3.0/3.1 and the a.out compiler backends will be removed in 5.0 (I think). The sigset_t and __sF changes are much more of a big-bang but I'm not sure how this can be avoided. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021031213557.GG6446>