From owner-cvs-all Thu Oct 31 23:17:23 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 221EC37B401; Thu, 31 Oct 2002 23:17:21 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A91443E4A; Thu, 31 Oct 2002 23:17:19 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA31440; Fri, 1 Nov 2002 18:17:04 +1100 Date: Fri, 1 Nov 2002 18:28:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Jeremy Cc: Alfred Perlstein , Peter Wemm , , Subject: Re: cvs commit: src/lib/libc/stdio findfp.c In-Reply-To: <20021031213557.GG6446@gsmx07.alcatel.com.au> Message-ID: <20021101180942.Q14336-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Nov 2002, Peter Jeremy wrote: > On 2002-Oct-31 22:15:51 +1100, Bruce Evans wrote: > >On Thu, 31 Oct 2002, Alfred Perlstein wrote: > > > >> * Bruce Evans [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