[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <53A164DB.1020305@huawei.com>
Date: Wed, 18 Jun 2014 18:07:23 +0800
From: Liu hua <sdu.liu@...wei.com>
To: <anton@...msg.org>, <ccross@...roid.com>, <keescook@...omium.org>,
<tony.luck@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Wang Nan <wangnan0@...wei.com>,
"peifeiyue@...wei.com" <peifeiyue@...wei.com>
Subject: Should Pstore(ramoops) records customized information?
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
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists