David VomLehn <dvomlehn@xxxxxxxxx> writes: >> > 2. Where would you suggest tying in? (Particularly since not all architectures >> > currently support kdump) >> >> No changes are needed kernel side. You just need an appropriate kernel and >> initrd for your purpose. > > I think I must still be missing something. I have dynamic data that I want > to preserve as I reboot from a failed kernel to a fresh new kernel. By > the time the fresh kernel starts init, the dynamic data (IP addresses, MAC > addresses) has been re-written with new values. This is why I'm trying to > preserve, but I may be running without disk or flash. This patch doesn't > preserve the data, but it gets it into the kernel so that it can be > preserved. At present, I'm preserving the data in a panic_notifier function, > but I am not wedded to that. At present, the data will be copied to a > section of memory retained across boots, but I know others will want to > write to flash. For memory retained across reboots, my inclination is to have a trivial little tty/console driver that writes into that retained memory. You can open the tty and write your user space data, and then at kernel panic time the kernel will write it's data. When people start writing to flash anything short of the most trivial writes is non-trivial code that requires sleeps etc, etc. Not something that is particularly reliable after a kernel failure. My inclination in that case is to use crash_kexec and a small crash kernel/initrd or if size is a real issue a standalone binary (ideally Aboot like so different embedded platforms can share). I'm sensitive about getting anything extra in the path before we call crash_kexec as that is likely to lead to destabilization of that path. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
