Eric W. Biederman wrote:
Amerigo Wang <amwang@xxxxxxxxxx> writes:Eric W. Biederman wrote:Amerigo Wang <amwang@xxxxxxxxxx> writes:No the crashdump mechanism is useless because user space is already broken and unusable.Again, why broken?To get a stock stat drive by hand I had to list about 5 kernel modules in the right magic order in /etc/kdump.conf Neither mount by label or mount by uuid when specified in /etc/kdump.conf I had to hack mkdumprd to get an initrd that even finds the proper disk to mount.You are saying that there is some difficulty to make a initrd for kdump, but I am sorry that I can't see any relations between this and my patch. What is your point here?You are trying to make it easier for end users. I am saying the problem is in user space. I am saying also that the kernel doesn't have a clue what you are going to load with kexec on panic to handle panics. Maybe it is a custom stand alone binary that only needs 5K. So the kernel doesn't have a clue what the right size to reserve.
So what? If you have 8G memory, would you mind 128M-5K memory to be wasted?The kernel doesn't have to reserve the exact amount of memory that a kexec kernel will use, it just finds a big enough size for all cases which already assumes the physical memory is large enough.
I think if what you were proposing was part of some coherent story for a complete implementation I would consider it more. Instead this just appears to be a reaction to how frustrating the user space implementation is, and fixing things in the kernel instead of in user space.
Yes, exactly, in fact I am doing another part which will allow us to take back of the reserved memory at run-time.
-- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |