Messages in this thread | | | Subject | Re: [lkcd-devel] Re: What's left over. | From | (Eric W. Biederman) | Date | 11 Nov 2002 11:03:43 -0700 |
| |
Linus Torvalds <torvalds@transmeta.com> writes:
> 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/
| |