Thank you for your comment. > Since the EFI backend has so little storage space ... perhaps it should have some overwrite rules built into it? I think so. If multiple triggers don't stride across the reboot, I think we can make an automated rule. > If this seems a plausible route ... we'd need to tabulate the overwrite rules. I think they are: > shutdown/reboot/kexec - can be overwritten by OOPS In my usecase, emergency_restart can be overwritten by OOPS > OOPS can be overwritten by panic > panic can never be overwritten I can make a patch in accordance with the rule above. Should it be in pstore layer? - introducing a new global variable storing a previous trigger. - deciding if we can continue by checking a value of previous trigger at the beginning of pstore_dump(). > I'd like to avoid a kernel parameter ... chances are too high that the machine would be automatically rebooted without the right boot > argument. But, I'm not sure if we can simply apply the rule above in case where multiple triggers stride across the reboot... In this case, emergency_restart cannot be overwritten by panic.. Anyway, I will consider the possibility of avoiding a kernel parameter. Seiji -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
