Messages in this thread | | | Date | Mon, 22 Nov 2010 08:55:34 -0800 | Subject | Re: [RFC] persistent store | From | Tony Luck <> |
| |
On Sun, Nov 21, 2010 at 5:59 PM, Huang Ying <ying.huang@intel.com> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |