From owner-freebsd-current Thu Sep 30 4:34:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by hub.freebsd.org (Postfix) with ESMTP id 4690F14D30 for ; Thu, 30 Sep 1999 04:34:38 -0700 (PDT) (envelope-from areilly@nsw.bigpond.net.au) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id VAA25401 for ; Thu, 30 Sep 1999 21:33:18 +1000 (EST) X-BPC-Relay-Envelope-From: areilly@nsw.bigpond.net.au X-BPC-Relay-Envelope-To: X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20] X-BPC-Relay-Info: Message delivered directly. Received: from areilly.bpc-users.org (CPE-24-192-49-170.nsw.bigpond.net.au [24.192.49.170]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id VAA17627 for ; Thu, 30 Sep 1999 21:33:12 +1000 (EST) Received: (qmail 80873 invoked by uid 1000); 30 Sep 1999 11:33:14 -0000 From: "Andrew Reilly" Date: Thu, 30 Sep 1999 21:33:14 +1000 To: Marcel Moolenaar Cc: current@FreeBSD.ORG Subject: Re: new sigset_t and upgrading: a proposal Message-ID: <19990930213314.A80221@gurney.reilly.home> References: <37F337CC.5E06911B@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <37F337CC.5E06911B@scc.nl> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote: > 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. As far as I can see, if this is the case, then this is the only problem. The tools built for a buildworld are tools that have to run on the _current_ platform, whatever that might be, with the new platform as a target. Therefore, they should be build against the existing system include files and libraries, and so should run on the existing system. With these tools, we build the world. As far as I can tell, the problem is installworld. Either: (a) The tools required to build the corresponding new kernel have to be secreted away in an "upgrade-bin" directory, so that they are still accessible after the install world (none of which will run on the existing kernel). (b) You build a new kernel before you do the install-world, reboot, and then installworld. I can't see any bennefit at all to (a), or any problem with (b). As I mentioned in a previous mail, why on earth should we expect user-land programs built to a new API to run on a kernel that doesn't support that API. The converse has always been true, though. Kernels usually support any new API and the previous one or more, so that old applications will still run. That said, I don't mind your idea of extending the stable kernel, but that is still really just a sneaky way of getting the user to build and install a kernel that supports the new API before they try to installworld. Isn't it? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message