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

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

[Hiraku Toyooka]

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

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

[Mark Salyzyn]

On 10/08/2015 06:52 PM, Hiraku Toyooka wrote:
> Hello,
>
> I'm trying to make the feature of multiple pmsg instances for ramoops.
I like it, in fact I encourage it.

This is somewhat/exactly what I did when I first created pmsg, but
decided to simplify to one instance for the first release because I was
unsure how many bona fide user space consumers there would be, so kept
the patch small. I kept the instance number 0 around to allow for
expanding this optional feature without introducing incompatibility. But
I sold the idea that multiple writers on single instance can occur if a
common protocol was used. For my own usage (Android) one instance was
more than enough.

Multiple instances does allow one to control individual content aging or
priority, I agree with your assessment, but make sure that you have a
bona fide user for it (even if it is just for yourself)?

NB: ToDo: device tree support for pstore configuration

Thanks

Sincerely -- Mark Salyzyn

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

[Hiraku Toyooka]

Hello Mark,

(I'm sorry for my late reply.)

Mark Salyzyn wrote:
>> I'm trying to make the feature of multiple pmsg instances for ramoops.
> I like it, in fact I encourage it.

Thank you.

> Multiple instances does allow one to control individual content aging or
> priority, I agree with your assessment, but make sure that you have a
> bona fide user for it (even if it is just for yourself)?

Yes. There are embedded devices which have limited NVRAM and no
HDD/SSD. Especially in our usage, the devices are industrial
machinery. When we catch a system failure, for fixing the root cause of
the failure, we often have to distinguish if it happend suddenly or if
there were signs long before the failure. Multiple pmsg can help this
kind of cause analysis with small NVRAM because higher priority
messages are preserved for a long time.

> NB: ToDo: device tree support for pstore configuration

Would you mean pstore backend's configuration (e.g.'mem_address' in
ramoops)?

Best regards,
Hiraku Toyooka