Messages in this thread | | | Subject | Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps. | From | (Eric W. Biederman) | Date | 04 Feb 2005 05:02:42 -0700 |
| |
ebiederm@xmission.com (Eric W. Biederman) writes:
> Hirokazu Takahashi <taka@valinux.co.jp> 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 crashkernel=size@location. 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 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/
| |