From owner-freebsd-current Fri Oct 1 5: 1:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0396614FBE for ; Fri, 1 Oct 1999 05:01:43 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA16254; Fri, 1 Oct 1999 14:01:35 +0200 (CEST) (envelope-from des) To: Marcel Moolenaar Cc: current@FreeBSD.ORG Subject: Re: new sigset_t and upgrading: a proposal References: <37F337CC.5E06911B@scc.nl> From: Dag-Erling Smorgrav Date: 01 Oct 1999 14:01:34 +0200 In-Reply-To: Marcel Moolenaar's message of "Thu, 30 Sep 1999 12:13:32 +0200" Message-ID: Lines: 22 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar writes: > 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) How about this: early in make world, we check whether or not the current kernel supports the new syscalls. If it does, good. If it doesn't, we build and load a small module which installs syscalls which translate the sigset_t stuff into something the old syscalls can grok. Does that make sense to any of you guys? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message