From owner-freebsd-current Thu Sep 30 2: 1:27 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 7334E150B1 for ; Thu, 30 Sep 1999 02:01:21 -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 TAA21927 for ; Thu, 30 Sep 1999 19:01:19 +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 TAA11373 for ; Thu, 30 Sep 1999 19:01:18 +1000 (EST) Received: (qmail 72413 invoked by uid 1000); 30 Sep 1999 09:01:19 -0000 From: "Andrew Reilly" Date: Thu, 30 Sep 1999 19:01:19 +1000 To: peter.jeremy@alcatel.com.au Cc: current@FreeBSD.ORG Subject: Re: HEADS UP: sigset_t changes committed Message-ID: <19990930190119.A71106@gurney.reilly.home> References: <37F23064.98EEBC67@scc.nl> <99Sep30.133847est.40341@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <99Sep30.133847est.40341@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 30, 1999 at 01:41:41PM +1000, Peter Jeremy wrote: > On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote: > >Before attempting to build world, you must make and install a new > >kernel. The new kernel will contain new syscalls that are needed during > >build world. doscmd is currently not being build because it needs fixing > >first. > > I'd like to voice my concerns with this change as well. The `normal' > upgrade procedure has always been to build and install a new world > before the new kernel. The only exception I'm aware of has been the > aout->elf transition (where a special build procedure was provided). Isn't this backwards? The kernel's the place that can (and must) have the backwards-compatability hooks, for the simple reason that even if you build the world, your ports and third-party applications have to keep running. Kernels are built and updated without corresponding buildworlds all the time. If you change something fairly fundamental about the interface specification for the userland-kernel interaction (say, going to 64-bit file offsets, for an equivelant example), then it seems pretty obvious to me that a program or library compiled to the new spec _cannot_ run on a kernel that doesn't implement it. How could it be otherwise? This seems to be a different argument to the one John-Mark is makeing: he isn't trying to _run_ his new world on his old kernel, just compile it. I agree that there are probably some curly issues regarding building a build-only set of tools. These are obviously going to be _different_ from the equivelant tools that you want built as part of the buildworld, being cross-compilers and so on. I don't know how close the build target is to that ideal. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message