Hello, I'm trying to make the feature of multiple pmsg instances for ramoops. I would like to discuss a possible way of getting the feature added to mainline.
The reason to add the multiple pmsg is to preserve particular messages over a long time, which are useful for failure analysis. Currently, we can use /dev/pmsg0 to log userspace messages into pstore. It is useful but we can use only one pstore buffer even if pstore backend module (e.g. ramoops) can create multiple buffers. When one messages happen to be generated repeatedly, old messages are overwritten by them regardless of the importance of the messages. Multiple pmsg will solves the problem. If we have two pmsg files: /dev/pmsg{0,1}, we can write all messages into /dev/pmsg0, while writing important ones into /dev/pmsg1. It can also be used for preserving important kernel messages selected by an userspace daemon. We have two types of files for pmsg. /dev/pmsg0 is for logging and /sys/fs/pstore/pmsg-$backend-0 is for read. We can extend these files like pmsg{0,1,2,...}, pmsg-$backend-{0,1,2,...}. To realize this /dev/pmsgN interface, pstore backend modules which manage multiple buffers for pmsg should tell the necessary numbers of buffer to pstore_register_pmsg() via pstore_info. In addition, for ramoops, I think the following works for ram.c are necessary at least. * Parse multiple pmsg size in module parameter, for example, pmsg_size=0x2000,0x1000,... * Change pmsg_size in ramoops_platform_data to a pointer of size array. struct ramoops_platform_data { ... - unsigned long pmsg_size; + unsigned long *pmsg_size; ... }; When a ramoops's backend driver registers the platform_data and want pmsg buffers, it should allocate an array of size for pmsg_size. (Although there is no ramoops's backend which uses pmsg currently) * Give an ID for each pmsg buffer, and modify some functions related to buffer allocation. What do you think about this idea? Best regards, Hiraku Toyooka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/