From: Anton Vorontsov <anton.vorontsov@linaro.org>
To: Colin Cross <ccross@android.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
John Stultz <john.stultz@linaro.org>,
arve@android.com, Rebecca Schultz Zavin <rebecca@android.com>,
Jesper Juhl <jj@chaosbits.net>,
Randy Dunlap <rdunlap@xenotime.net>,
Stephen Boyd <sboyd@codeaurora.org>,
Thomas Meyer <thomas@m3y3r.de>,
Andrew Morton <akpm@linux-foundation.org>,
Marco Stornelli <marco.stornelli@gmail.com>,
WANG Cong <xiyou.wangcong@gmail.com>,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
linaro-kernel@lists.linaro.org, patches@linaro.org,
kernel-team@android.com
Subject: Re: [PATCH 04/11] persistent_ram: Introduce persistent_ram_new()
Date: Tue, 15 May 2012 17:22:33 -0700 [thread overview]
Message-ID: <20120516002232.GA18883@lizard> (raw)
In-Reply-To: <CAMbhsRR3gsajDCyODgf0XrtEr5Jeeo7yPXxk_R6JfVkk-kGvyQ@mail.gmail.com>
Hello Colin,
On Mon, May 14, 2012 at 05:37:56PM -0700, Colin Cross wrote:
[...]
> even worse, mem= from the bootloader. Mixing the two methods together
> would be confusing.
Yes, mixing is discouraged. The mem= hack is mostly useful for
developers, for hacking random kernels. Even on x86 it is
useful, when you want to grab an oops, but you don't have say
netconsole, or HW really screwed up and you don't have any
means to get the oops log, ramoops may become quite useful.
But in the Android phone scenario, if you want to have this
feature into production kernels, platforms should register
the ramoops platform driver, as they were doing before.
> Either persistent_ram_early_init should be
> removed completely (or replaced with something that is easier to
> register ramoops into), or ramoops should use
> persistent_ram_init_ringbuffer like ram_console does.
Yep, this was indeed my original idea: persistent_ram_early_init
should go.
Boards (or generic arch/ or arch/mach-* code that knows memory
layout) will have to just do two things:
1. Wisely and early call memblock_reserve().
2. Register a ramoops platform device pointing to the reserved
memory.
This is actually exactly the same as you were doing with
ram_console:
1. Platform were adding an entry to the global list of persistent
ram zones, and then were calling persistent_ram_early_init()
somewhere in the arch/ code (at least that's how I understood
the idea of the code, as there are currently no in-tree users).
2. Then platforms were registering a ram_console platform device,
and the driver would find out the needed zone by matching on
the device name.
Thinking about it, the whole thing was actually abusing
the device-driver model a little bit. So things are just easier
now.
Thanks!
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
next prev parent reply other threads:[~2012-05-16 0:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-12 0:15 [PATCH 0/11] Merge ramoops and persistent_ram, generic pstore RAM backend Anton Vorontsov
2012-05-12 0:17 ` [PATCH 01/11] persistent_ram: Remove prz->node Anton Vorontsov
2012-05-12 0:17 ` [PATCH 02/11] persistent_ram: Fix buffer size clamping during writes Anton Vorontsov
2012-05-13 16:56 ` Dan Carpenter
2012-05-13 20:38 ` Anton Vorontsov
2012-05-14 3:23 ` Colin Cross
2012-05-14 4:17 ` Greg Kroah-Hartman
2012-05-12 0:17 ` [PATCH 03/11] persistent_ram: Introduce persistent_ram_post_init() Anton Vorontsov
2012-05-12 0:17 ` [PATCH 04/11] persistent_ram: Introduce persistent_ram_new() Anton Vorontsov
2012-05-15 0:37 ` Colin Cross
2012-05-16 0:22 ` Anton Vorontsov [this message]
2012-05-12 0:17 ` [PATCH 05/11] persistent_ram: Introduce persistent_ram_vmap() Anton Vorontsov
2012-05-12 0:17 ` [PATCH 06/11] persistent_ram: Make it possible to use memory outside of bootmem Anton Vorontsov
2012-06-06 21:10 ` Colin Cross
2012-06-06 22:11 ` Anton Vorontsov
2012-05-12 0:18 ` [PATCH 07/11] persistent_ram: Introduce persistent_ram_free() Anton Vorontsov
2012-05-12 0:18 ` [PATCH 08/11] ramoops: Move to fs/pstore/ram.c Anton Vorontsov
2012-05-14 21:34 ` Kees Cook
2012-05-16 0:19 ` Anton Vorontsov
2012-05-15 15:12 ` Shuah Khan
2012-05-16 7:30 ` Anton Vorontsov
2012-05-16 15:17 ` Shuah Khan
2012-05-12 0:18 ` [PATCH 09/11] persistent_ram: Move to fs/pstore/ram_core.c Anton Vorontsov
2012-05-14 21:43 ` Kees Cook
2012-05-12 0:18 ` [PATCH 10/11] pstore/ram: Switch to persistent_ram routines Anton Vorontsov
2012-05-14 22:21 ` Kees Cook
2012-05-16 6:14 ` Anton Vorontsov
2012-05-16 12:44 ` Kees Cook
2012-05-12 0:18 ` [PATCH 11/11] pstore/ram: Add ECC support Anton Vorontsov
2012-05-14 22:22 ` Kees Cook
2012-05-14 15:58 ` [PATCH 0/11] Merge ramoops and persistent_ram, generic pstore RAM backend Greg Kroah-Hartman
2012-05-14 16:30 ` Shuah Khan
2012-05-14 20:45 ` Anton Vorontsov
2012-05-14 20:55 ` Shuah Khan
2012-05-15 15:53 ` Greg Kroah-Hartman
2012-05-15 6:07 ` Marco Stornelli
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=20120516002232.GA18883@lizard \
--to=anton.vorontsov@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arve@android.com \
--cc=ccross@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jj@chaosbits.net \
--cc=john.stultz@linaro.org \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.stornelli@gmail.com \
--cc=patches@linaro.org \
--cc=rdunlap@xenotime.net \
--cc=rebecca@android.com \
--cc=sboyd@codeaurora.org \
--cc=thomas@m3y3r.de \
--cc=xiyou.wangcong@gmail.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).