From owner-freebsd-current Thu Sep 30 3:43:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id CC94115070 for ; Thu, 30 Sep 1999 03:43:37 -0700 (PDT) (envelope-from freebsd-current@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id MAA54656 for current@FreeBSD.org; Thu, 30 Sep 1999 12:13:42 +0200 (CEST) (envelope-from freebsd-current@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for current@FreeBSD.org (current@FreeBSD.org) To: current@FreeBSD.org Date: Thu, 30 Sep 1999 12:13:32 +0200 From: Marcel Moolenaar Message-ID: <37F337CC.5E06911B@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: new sigset_t and upgrading: a proposal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, In the recent discussion about the breakage of the upgrade path from -stable to -current numerous suggestions and other kinds of remarks have been made. In this light I have the following proposal. Please share your thoughts... NOTE: This proposal only discusses upgrading from -stable to -current. Users already running -current are expected to be capable of building a kernel before doing a make world. The problem ----------- When doing a make world, tools are being built that are used by the build process. This is to make sure that the tools are appropriate for doing a make world. The problem we now face is that the sigset_t change causes this to break. The tools that are being built use new syscalls not present in a kernel. Not only that, the new tools expect a different sigframe in general. So, the problem can be split into: A) New syscalls using the new sigset_t (sigaction and so on) B) A new sigframe (new siginfo, no sigcontext but ucontext_t) The solution ------------ Sub-problem A (syscalls) can be easily handled if the syscalls are added to a -stable kernel. The new sigset_t and dependencies used by these syscalls are converted back and are handled by the kernel in the normal way. The assumption here is that the tools that are needed by the make world are not depended on the extra signals and/or RT signals. Sub-problem B (sigframe) doesn't need to be handled, because: 1. none of the tools required for doing a make world depends on siginfo_t. The only C sources where SA_SIGINFO can be found (not counting /sys) are: ./contrib/sendmail/src/conf.c ./gnu/usr.bin/rcs/lib/rcsutil.c 2. The only program that uses sigcontext (and therefore possibly sigreturn) is doscmd, which is not needed for anything other than DOS emulation. This simply means that the sigframe changes are not visible in general and that the old sigframe should work for the binaries al well. Pros ---- o It's relatively easy. o It won't interfere with the normal operation of a -stable machine and thus won't stretch the meaning of "stable" as a complete backport would do. o It increases inoperability between -stable and -current. o It doesn't require to change the already complex build process. Cons ---- o Upgrading from 3.3 and before to -current is only possible after an upgrade to post 3.3. o It's still hypothetical. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message