Date: Fri, 1 Nov 2002 18:28:24 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Jeremy <peter.jeremy@alcatel.com.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: <20021101180942.Q14336-100000@gamplex.bde.org> In-Reply-To: <20021031213557.GG6446@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Nov 2002, Peter Jeremy wrote: > 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). Peter (Wemm) did this for some syscalls. We could make this easy by not sending SIGSYS. OTOH, I found SIGSYS useful for pointing to this problem fast. It broke inetd and syslogd correctly when they got out of sync with the kernel. These utilities are too uncritical to check for errors from unimportant syscalls like sigaction(). > >> 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). __sF doesn't. It's just more of a nuisance for the kernel and userland to become incompatible concurrently. E.g., I would need to recompile applications that referenced __sF externally. Then the reccompiled versions wouldn't work without a new kernel, since they use the new sigaction(). > 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. Old applications have a good chance of running on -current. The reverse is not true ... > 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. ... but apart from these changes they (current applications) often do run on old kernels unless they are very system-specific. The a.out -> ELF incompatibilities and maybe the sigset_t changes were unavoidable, but the others are mostly just from poor organization. Bruce 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?20021101180942.Q14336-100000>