From owner-freebsd-current Fri Oct 1 14: 2:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 8407A14D26 for ; Fri, 1 Oct 1999 14:02:50 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.02 #1) id 11X9pJ-0002WB-00; Fri, 1 Oct 1999 21:02:49 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id XAA59781; Fri, 1 Oct 1999 23:02:43 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37F52173.8F4B6FF8@scc.nl> Date: Fri, 01 Oct 1999 23:02:43 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: des@flood.ping.uio.no, current@FreeBSD.ORG Subject: Re: new sigset_t and upgrading: a proposal References: <199910011936.PAA11014@pcnet1.pcnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > Marcel Moolenaar wrote: > > Dag-Erling Smorgrav wrote: > > > > > > 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? > > > > That has been proposed by someone (sorry, I can't remember who exactly). > > We still need a consensus as to what we should do. Personally, I now > > like to fix this at the core of the problem: truly support > > cross-compilations. This implies (IMO) that the source tree is never > > used to build the tools with which a world is built (ideally). Such a > > solution may take too long to be implemented to be used as a solution > > now, though. > > But this still doesn't entirely solve the problem. You still have > to build and install a new kernel before installing the world. > While this is typically what most -current folks do anyways, it > still prevents backing up to a previous kernel after the install > world. You can easily install a kernel as part of the upgrade process. A complete upgrade would be something like: 1. Verify and/or install cross-compilation tools 2. Build world 3. Build kernel 4. Copy tools that are used by the install process 5. install kernel 6. install world 7. reboot If you install a kernel before installing world, you can easily recover when the install world fails: reboot. The new kernel is capable of running those binaries that got installed before the breakage. > It seems like libc should be built to be compatible with the kernel > that is currently running. After installing world and testing the > new kernel, a subsequent make world (or some other target to get > just the libs) can be done to make the libs use the new syscalls. You still want to use the source tree to tools that run on the machine that does the building. Assume for a moment that such can't be done. What you get is real cross-compilation. > This is why I kind of like (was it?) Peter Wemms libc hack. It's a solution that may work out very well, yes. But it seems to me that cross-compilation is on everybodies wishlist for as long as FreeBSD exists (well almost :-) That's why I'm pressing it. This doesn't rule out interim solutions of course. Real cross-compilation may not be worth the effort/problems, but you can't really tell if you haven't tried it... -- 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