All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Stornelli <marco.stornelli@gmail.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>,
	"shuahkhan@gmail.com" <shuahkhan@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5] ramoops: use pstore interface
Date: Tue, 10 Apr 2012 10:34:22 +0200	[thread overview]
Message-ID: <4F83F08E.6070304@gmail.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170D020E@ORSMSX104.amr.corp.intel.com>

Il 09/04/2012 23:42, Luck, Tony ha scritto:
>> The patch breaks ramoops module unloading.  Tony says there's "no
>> credible end-user case" for this and Marco promptly provided one,
>> which was ignored.
>
> I'm not sure that I understood Marco's use case. He said:
>
>> First of all ramoops was born mainly for debug purpose and
>> to help the maintainability of a product. I used it in systems
>> where the uptime (so no reboot) was important. So it can be
>> very useful for me load the module, gather logs and unload it
>> for example. A kernel panic is not recoverable so the reboot
>> is needed but it's not always true for a kernel oops.
>
> In the non-crashed oops case ... aren't all the logs you need
> in /var/log/messages?
>
> -Tony

Maybe you right, but it could be useful to have a "single log point" 
especially for automatic/semi-automatic log gathering. I'm not sure we 
can *always* read from messages in case of non-crashed oops. Sure, it 
will be possible after a reboot, but if /var was mounted with tmpfs (on 
embedded systems it's possible :)) we have no log.

PS: It's only a brainstorming on all the possible situation :)

Marco

  reply	other threads:[~2012-04-10  8:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-17 23:58 [PATCH v5] ramoops: use pstore interface Kees Cook
2012-01-18 22:06 ` Andrew Morton
2012-01-18 22:16   ` Kees Cook
2012-01-18 22:40     ` Seiji Aguchi
2012-01-18 22:47       ` Kees Cook
2012-01-18 23:20         ` Seiji Aguchi
2012-01-21  8:33           ` Marco Stornelli
2012-04-02 20:39             ` Shuah Khan
2012-04-02 20:51               ` Kees Cook
2012-04-02 21:09                 ` Andrew Morton
2012-04-09 21:33                 ` Andrew Morton
2012-04-09 21:42                   ` Luck, Tony
2012-04-10  8:34                     ` Marco Stornelli [this message]
2012-04-10 16:11                       ` Kees Cook
2012-04-11  6:33                         ` Marco Stornelli
2012-04-11  6:37                           ` Andrew Morton
2012-01-18 22:37   ` Luck, Tony

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=4F83F08E.6070304@gmail.com \
    --to=marco.stornelli@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shuahkhan@gmail.com \
    --cc=tony.luck@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.