On Sun, Nov 21, 2010 at 5:59 PM, Huang Ying <ying.huang@xxxxxxxxx> wrote: > This patch provides a general "read" interface for kmsg_dumper and some > other persistent storage users. Another possible choice is to just > extend the original interface to add persistent store support. For > example, we can add a "read" function in kmsg_dumper, and output the > content of persistent store via extend /dev/kmsg via prefix every line > comes from persistent store or adding some "ioctl" to do that. (But it > seems that nobody likes "ioctl"). In Linux (and Unix before it) "everything is a file" ... but this doesn't work very well if the file has internal structure (e.g. is made of records that can be individually changed or deleted). A filesystem seems a much better model. >> "writer" which writes a record with a type to the persistent store > > I think it is necessary to require this to be NMI safe (in comments?), > because hardware error handler may need to write to persistent storage > in NMI context. Or we can add a "flag" field to let storage provider > advocate its capability of NMI safe. I can add a comment to pstore.h to document the NMI-safe requirement for the "writer" function. >> - Which device(s) should error records be written to? >> All of them? Start with one and move on when it is >> full? Write some types of records to one device? > > The persistent storage may be full, and the writing may fail. So I think > we can just try to write one by one, until the first success writing. A good option - if we ever find someone luck enough to have more than one persistent store device. >> + sysfs_remove_bin_file(&pstore_kset->kobj, &search_pstore->attr); > > It seems that the corresponding memory is not freed after erasing. Ouch! Good catch. Will add a kfree() -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
