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:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
