[RFD] pstore: pmsg: ramoops: add multiple pmsg instances

[Hiraku Toyooka <hiraku.toyooka.gu@hitachi.com>]

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