Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Sep 1999 19:01:19 +1000
From:      "Andrew Reilly" <areilly@nsw.bigpond.net.au>
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>
In-Reply-To: <99Sep30.133847est.40341@border.alcanet.com.au>
References:  <37F23064.98EEBC67@scc.nl> <99Sep30.133847est.40341@border.alcanet.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990930190119.A71106>