> 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
^^^^^^^^^^^^^^^^^^^^^^^
Why are the tools being built using new syscalls? What causes this?
I can't find it from a quick read of the Makefiles. Should not a
proper adjustment to a -I flags on a cc command line some place fix
this?
Your changes have exposed a very serious short comming of the tools
target, and as others have pointed out, if we ever even want to think
about getting close to cross compiliation this target must work
correctly.
Please search mail archives about many various discussions about this
over the 6 year history of FreeBSD.
IMHO, the only ``correct'' fix for the latest incarnation of the
problem is to finally once and for all fix the cross compilation
environment instead of using a half cooked tools: target to deal
with certain problems.
> 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.
Or even easier to fix, never call them. What in the world is building
in the tools target with new syscalls???? All of that stuff is suppose
to be built using the currently installed library/kernel API. If not
we are never going to get to cross-compilation.
> 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.
Good.
>
> 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.
Not good.
> o It's still hypothetical.
And in IMNSHO, should probably remain that way. I like real solutions,
not fragile bandaids.
I think your a pretty smart fellow, anyone who was able to do this with
the signal code and have it come out working as well as it has (glenned
from other posts about people who have made the jump in -current) should
be able to solve yet another engineering problem that was not accounted
for at the beginning of your change. You probably solved a dozen of
them during this work, whats one more :-)
I furthermore think that if you put your mindset in the frame that this
is just another engineering problem you'll come up with the ``right
solution'' that will make everyone happy.
--
Rod Grimes - KD7CAX - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
