[EMAIL PROTECTED] (Eric W. Biederman) writes: > Hirokazu Takahashi <[EMAIL PROTECTED]> writes: > > > Most of this just results in easier management between the pieces. > > > Which is a good thing. However at the moment I don't think it > > > simplifies any of the core problems. I still need to reserve > > > a large hunk of physical address space early on before any > > > DMA transactions are setup to hold the new kernel. > > > > I agree that my idea is not essential at the moment. > > > > > So while I am happy to see patches that improve this I don't > > > actually care right now. > > > > ok.
Thinking about this some more this does have a significant aspect on the design. For architectures that support this, on the primary kernel the command line option becomes: crashkernel=size instead of [EMAIL PROTECTED] Which means the kernel needs to call alloc_bootmem instead of reserve_bootmem. So it results in a primary kernel implementation difference. In addition if we really can push all of the dump specific functionality into user space as it appears we can, this allows a generic kernel to be used for the crash dump process. It will probably still be a special hardened build where reliability is more important than performance. So that any micro hit we take in performance by modifying __pa() and __va() will be irrelevant. I like it. I have already demonstrated that there is a general technique that any architecture can use to build a kernel that runs at a non-default address. So for the architectures that cannot build a PIC kernel there is still a proven solution available, it simply will not be as nice to manage. x86_64 should pretty straight forward. i386 will be a little more difficult but doable. Patches are still welcome. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
