No, the argument was that by the time the kernel crashes, that
it might be impossible to trust the device driver to be able to write out
a crash dump without stomping on something that should not be stomped upon.
One frequent cause of crashes is bad memory, and in such cases, it would
be rather hard to determine what parts of the kernel are still sane enough
to write a crash dump.
There are two possible solutions - one is to wait until bootup to
offer the user a chance to write the contents of memory to someplace, and
the second is to essentially say that one given device (e.g. IDE disk
driver)
will be the one to write the crash dump. Note that there must be a way of
disabling crash dumps if the panic occurs inside of the driver that must
write out the dump, but if a memory fault is responsible for the problem,
it will be impossible to guarantee much of anything.
If we want to write the crash dump on bootup, then we need to get
in as soon as possible, as we would want to be able to preserve as much
information as possible (you would always lose something, however).
-Eric
-- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep."