linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liu hua <sdu.liu@huawei.com>
To: "Luck, Tony" <tony.luck@intel.com>,
	"anton@enomsg.org" <anton@enomsg.org>,
	"ccross@android.com" <ccross@android.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>,
	"peifeiyue@huawei.com" <peifeiyue@huawei.com>
Subject: Re: Should Pstore(ramoops) records customized information?
Date: Thu, 19 Jun 2014 20:21:15 +0800	[thread overview]
Message-ID: <53A2D5BB.5040500@huawei.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F32838E10@ORSMSX114.amr.corp.intel.com>

On 2014/6/19 1:50, Luck, Tony wrote:

Hi Tony,

Thanks for you reply.

>> (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, ...)
> 
> Don't you need to match up the number of back-end ring buffer regions
> with the number of users in the kernel that call alloc_pstore_region()?
> 
> Or do you envision that the backend can create these regions on demand?

I have do some experiments on ramoops. This may be realizable.

This idea comes from real products'demands . Becasue ram is rather cheap and
we do not need to add new hardware, product engineers want to record several
kinds of messages into reserved ram. (including kernel snapshot, softlookup, ftrace;
panic, even the user-space events and so on). Different products usually care about
different messages.

So we realized a mechanism named "KBOX" to provide ring-buffer alloction on reserved memory.
Kernel users can allocate and use a ring buffer. I think pstore(ramoops) may also need
this feature.

BTW, I note that "extern struct pstore_info *psinfo" locates in
fs/pstore/internal.h. So users out of directory "fs/pstore/" can not use pstore to
record messages. We do not want other kernel users to use pstore, right?  And can we
break this?

> 
> Would different users need different sized regions? I think logging of
> console messages might be able to work with a smaller ring buffer
> than the ftrace logger. So perhaps we need a "size" argument when allocating?

Yes, I will add this to my RFC patches.
> 
> Since these "regions" are in fact "ring buffers", the name of the allocation
> routine should make that clear.  So call it "pstore_alloc_ring_buffer()"
Yes, ditto..

> After the system hangs/crashes ... how would you like pstore to
> name these objects in /sys/fs/pstore/ for applications to pick them
> up for analysis?  Maybe pstore_alloc_ring_buffer() needs a "char *name"
> argument as well as a size?
> 
ditoo.. Since other backends like efi and erst may can not privide such ring buffer.
So pstore_alloc_ring_buffer should be a funciton pointer of pstore_info struct.

Thanks very much again. if pstore can accept this feature, it will be a great news for us.
we will drop our "KBOX" gradually, using pstore instead. If necessary, I will try to send
patch series to do this. What do you think about it?

Thanks,
Liu Hua



> -Tony
> 



  reply	other threads:[~2014-06-19 12:21 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 ` Should Pstore(ramoops) records customized information? Liu hua
2014-06-18 17:50   ` Luck, Tony
2014-06-19 12:21     ` Liu hua [this message]
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=53A2D5BB.5040500@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).