Eric W. Biederman wrote:
In general I figure that whoever builds the kernel and initrd should be responsible for testing and figuring out the amount of memory needed. The primary kernel has no idea what is going to loaded in there and as such no real idea how much memory is needed.
Yeah, that is exactly why I _didn't_ pick the idea of reserving memory automatically and silently without "crashkernel=auto".
If a user specifies "crashkernel=auto", that means he/she has no idea how much memory to be reserved, he/she wants to let the kernel to decide. Kernel should know better than the user in this situation.
For kernel developers, "crashkernel=auto" should save a lot. You seem agree with this one.You also have to build (or at least load) the whole kdump image after the system boots, and configure someplace for this to be saved. What class of problems do you expect to catch with this?Again, try to save the user from choosing numbers for "crashkernel=".The user being kernel developers? Whoever builds the kernel and initrd should be responsible for testing and figuring this out. In a distro context installers etc should be able to setup good defaults so end users don't have to worry about this.
For users, they rely on the distro which can always specify "crashkernel=auto" now, not different numbers for different arch, since "crashkernel=auto" is designed to be safe for all cases. Also saves many work...
What has me puzzled is that the mkdumprd that ships with fedora isn'tusable without patching, and it seems to be steadily getting worse.Please explain why it is not usable? The patch won't break the userspace, since it modifies the "crashkernel=" command line dynamically.No the crashdump mechanism is useless because user space is already broken and unusable.
Again, why broken? Thanks. -- 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
![]() |