Hi,
In the recent discussion about the breakage of the upgrade path from
-stable to -current numerous suggestions and other kinds of remarks have
been made. In this light I have the following proposal. Please share
your thoughts...
NOTE: This proposal only discusses upgrading from -stable to -current.
Users already running -current are expected to be capable of building a
kernel before doing a make world.
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.
So, the problem can be split into:
A) New syscalls using the new sigset_t (sigaction and so on)
B) A new sigframe (new siginfo, no sigcontext but ucontext_t)
The solution
------------
Sub-problem A (syscalls) can be easily handled if the syscalls are added
to a -stable kernel. The new sigset_t and dependencies used by these
syscalls are converted back and are handled by the kernel in the normal
way. The assumption here is that the tools that are needed by the make
world are not depended on the extra signals and/or RT signals.
Sub-problem B (sigframe) doesn't need to be handled, because:
1. none of the tools required for doing a make world depends
on siginfo_t. The only C sources where SA_SIGINFO can be
found (not counting /sys) are:
./contrib/sendmail/src/conf.c
./gnu/usr.bin/rcs/lib/rcsutil.c
2. The only program that uses sigcontext (and therefore
possibly sigreturn) is doscmd, which is not needed for
anything other than DOS emulation.
This simply means that the sigframe changes are not visible in general
and that the old sigframe should work for the binaries al well.
Pros
----
o It's relatively easy.
o It won't interfere with the normal operation of a -stable machine
and thus won't stretch the meaning of "stable" as a complete
backport would do.
o It increases inoperability between -stable and -current.
o It doesn't require to change the already complex build process.
Cons
----
o Upgrading from 3.3 and before to -current is only possible after
an upgrade to post 3.3.
o It's still hypothetical.
--
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
