> On 9 Nov 2002, Eric W. Biederman wrote:
> >
> > And despite my utter puzzlement on why you want the syscall cut in two.
>
> I'm amazed about your puzzlement, since everybody else seem to get my
> arguments, but as long as you play along I don't much care.
I think this comes from being the guy down in the trenches implementing
the code. And it is sometimes hard to look up, far enough to have design
discussions.
I totally agree that having a load/exec split is the right
approach now that I can imagine an implementation where the code will
actually work for the panic case. Before it felt like lying. Doing
the split-up, promising that kexec on panic will work eventually,
when I could not even see it as a possibility was at the core of my
objections.
What brought me around is that I can add a flag field to kexec_load.
With that flag field I can tell the kernel please step extra carefully
this code will be used to handle kexec on panic. Without that I may
be up a creek without a paddle for figuring out how to debug that code.
To be able to support this at all I have had to be very creative in
inventing debugging code. Which is why I have the serial console
program kexec_test. It provides visibility into what is happening
when nothing else will. That and memtest86 which will occasionally
catch DMA's that have not been stopped, (memory errors on good ram) I
at least have a place to start rather than a blank screen when
guessing why the new kernel did not start up.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/