From: Liu hua <sdu.liu@huawei.com>
To: <anton@enomsg.org>, <ccross@android.com>, <keescook@chromium.org>,
<tony.luck@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>,
"peifeiyue@huawei.com" <peifeiyue@huawei.com>
Subject: Should Pstore(ramoops) records customized information?
Date: Wed, 18 Jun 2014 18:07:23 +0800 [thread overview]
Message-ID: <53A164DB.1020305@huawei.com> (raw)
In-Reply-To: <539E6D4D.5000802@huawei.com>
Hi Kees or Colin or Tony or Anton,
We are very interested in Pstore, which provides a mechanism to save information
when machine is going to die. It is much lighter than kdump. So we can deploy it on
our real products. Because our product runs on several platforms (x86,arm and mips),
we prefer ramoops as pstore backend. For ramoops backend, now we can save dmesg,
console and ftrace inforamtion to different memory regions. It is very good, but
can we do something more?
For kmsg_dumper or console, we mixed messages together. So some important meaasges
may be flooded with dispensable ones. Pstore does not provide a way to let us
determine which message to record, which to discard. And
So can we introduce a customized information recording mechanism?
Something like this:
(1) The backend (ramoops) provides servel memory regions staticly. Each region
is a ring buffer, which does not connect with certain PSTORE_TYPE_ID. So no one
can modify or use it before allocation.
(2) A pstore user allocs a memory region, pstore will return a pstore_type_id.
pstore_type_id = alloc_pstroe_region()
(3) This user record certain message to this region.
psinfo->write(pstore_type_id, ...)
By doing this:
(1) The console and ftrace message recording is also supported. we just need to call
alloc_pstore_region() before saving such messages.
(2) We can realize a mechanism like black box in aircraft. if we record certain kind of
messages to a sigle region. We do not need to care other type messages to overlap it.
we can allways get the latest messages of each type.
(3) Anyone in kernel or modules can use this mechanism, if they alloc a region.
Thanks,
Liu Hua
.
next parent reply other threads:[~2014-06-18 10:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <539E6D4D.5000802@huawei.com>
2014-06-18 10:07 ` Liu hua [this message]
2014-06-18 17:50 ` Should Pstore(ramoops) records customized information? Luck, Tony
2014-06-19 12:21 ` Liu hua
2014-06-19 23:42 ` Luck, Tony
2014-06-20 10:47 ` Liu hua
2014-06-25 0:41 ` Zhang, Yanmin
2014-06-25 13:08 ` Liu hua
2014-06-26 0:57 ` Zhang, Yanmin
2014-06-27 12:06 ` Liu hua
2014-06-30 9:05 ` Zhang, Yanmin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53A164DB.1020305@huawei.com \
--to=sdu.liu@huawei.com \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peifeiyue@huawei.com \
--cc=tony.luck@intel.com \
--cc=wangnan0@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).