linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Luck <tony.luck@intel.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Waychison <mikew@google.com>,
	linux-kernel@vger.kernel.org, Matt_Domsch@dell.com
Subject: Re: [PATCH 3/3] efi: Add support for using efivars as a pstore backend
Date: Tue, 21 Jun 2011 10:12:21 -0700	[thread overview]
Message-ID: <BANLkTimh8dWmYJFJY9e5sPHfYuL_FK1vbQ@mail.gmail.com> (raw)
In-Reply-To: <20110621151040.GB7476@srcf.ucam.org>

>> How do I configure this thing?
>
> You don't. I'll be posting a patch for pstore that lets you choose the
> backend - that can be used to disable this functionality at boot time.

For EFI - you need to configure CONFIG_PSTORE (which you may not be
able to see until you first set CONFIG_MISCFILESYSTEMS) ... and of course
you'll need CONFIG_EFIVARS.  At the moment (until Matthew provides the
new pstore boot time choosing argument, you might need to set CONFIG_ACPI_APEI=n
because otherwise its a link order race to see who gets to register
their back end first.

Once you boot into that kernel you can mount pstore:

 # mount -t pstore - /dev/pstore

and once you crash/shutdown/reboot and mount it again - you should see
some files
in /dev/pstore with the tail of the saved console log from the
previous kernel. Remove
the files to clear the underlying store (in your case delete the efi
variables that saved
the text of the console log).

>> >+    sprintf(stub_name, "dump-type%u-%u-", type, part);
>>
>> The format specifier here uses an unsigned, but your series passes
>> part around as a signed int.  If part is truely non-negative,
>> consider changing it to unsigned?
>
> The variable name is fundamentally meaningless. Just think of it as a
> binary representation of the data. Formatting it as a signed integer
> would break the parsing. But you're right that there's probably no
> reason for it to be signed in the first place - Tony?

part numbers are integers (1, 2, 3 ...) - so making it unsigned makes sense.

>> Hmm.  pstore doesn't have a pstore_unregister?  This is unfortunate
>> because this breaks efivars module unloading :(
>
> Userspace really ought to depend on efivars being available on EFI
> systems. I don't think losing the ability to unload it is a big loss.

If there is a strong demand for this - maybe someone will write a patch
for it?  But in general, once you attach a backend to pstore, I'd expect
you to leave it attached - you don't know whether the system is about
to crash, and you'd lose the kernel log if you crashed while the backend
was not registered.

-Tony

  reply	other threads:[~2011-06-21 17:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-06 19:38 [PATCH 1/3] pstore: Extend API Matthew Garrett
2011-06-06 19:38 ` [PATCH 2/3] pstore: Add extra context for writes and erases Matthew Garrett
     [not found]   ` <BANLkTinHYQ14A7vzTxA1c2frxUVE6HWNQg@mail.gmail.com>
2011-06-06 21:43     ` Tony Luck
2011-06-06 21:47       ` Matthew Garrett
2011-06-10  4:00         ` Matt Domsch
2011-06-10  7:12           ` Mike Waychison
2011-06-20 22:27             ` Tony Luck
2011-06-20 22:29               ` Mike Waychison
2011-06-06 19:38 ` [PATCH 3/3] efi: Add support for using efivars as a pstore backend Matthew Garrett
2011-06-06 23:11   ` Tony Luck
2011-06-07 15:47   ` Seiji Aguchi
2011-06-07 15:58     ` Matthew Garrett
2011-06-07 18:04   ` Randy Dunlap
2011-06-21  0:56   ` Mike Waychison
2011-06-21 15:10     ` Matthew Garrett
2011-06-21 17:12       ` Tony Luck [this message]
2011-06-21 20:16       ` Mike Waychison
2011-06-21 20:18         ` [PATCH 1/4] efivars: String functions Mike Waychison
2011-06-21 20:18         ` [PATCH 2/4] efivars: introduce utf16_strncmp Mike Waychison
2011-06-21 20:18         ` [PATCH 3/4] efivars: Use string functions in pstore_write Mike Waychison
2011-06-21 20:18         ` [PATCH 4/4] efivars: Introduce PSTORE_EFI_ATTRIBUTES Mike Waychison
2011-06-21 20:22         ` [PATCH 3/3] efi: Add support for using efivars as a pstore backend Matthew Garrett

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=BANLkTimh8dWmYJFJY9e5sPHfYuL_FK1vbQ@mail.gmail.com \
    --to=tony.luck@intel.com \
    --cc=Matt_Domsch@dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikew@google.com \
    --cc=mjg59@srcf.ucam.org \
    /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).