Hi, > There is also this series, > > http://lists.infradead.org/pipermail/kexec/2011-July/005258.html > > It seems awkward that pstore is in fs/pstore/ then pstore ends up as the "back end" where it could just be the whole solution. I just wanted to avoid deadlocks of pstore and its drivers such as mtdoops, ramoops, and efi_pstore in panic case. That is still under discussion in lkml. I have no objection to modifying mtdoops/ram_console to use pstore. >pstore does seems to have the nicest user interface (might be better in debugfs tho). If someone wanted to move forward with pstore they would have to write some some sort of, > >int pstore_register_simple(unsigned long addr, unsigned long size); > >to cover all the memory areas that aren't transaction based, or make pstore accept a platform_device. If you would like to introduce new feature to pstore, Tony Luck is the appropriate person to discuss. Seiji -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href