From: Marco Stornelli <marco.stornelli@gmail.com>
To: Sergiu Iordache <sergiu@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Ahmed S. Darwish" <darwish.07@gmail.com>,
Artem Bityutskiy <Artem.Bityutskiy@nokia.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] char drivers: ramoops record_size module parameter
Date: Tue, 28 Jun 2011 19:17:04 +0200 [thread overview]
Message-ID: <4E0A0C90.2010305@gmail.com> (raw)
In-Reply-To: <BANLkTiniM96M16TnPC9sXNg-rhDD1RT4KOcD1HJUH-Nu+7hY2Q@mail.gmail.com>
Il 28/06/2011 18:38, Sergiu Iordache ha scritto:
> On Mon, Jun 27, 2011 at 11:39 PM, Marco Stornelli
> <marco.stornelli@gmail.com> wrote:
>> Hi,
>>
>> 2011/6/28 Sergiu Iordache<sergiu@chromium.org>:
>>> The size of the dump is currently set using the RECORD_SIZE macro which
>>> is set to a page size. This patch makes the record size a module
>>> parameter and allows it to be set through platform data as well to allow
>>> larger dumps if needed.
>>>
>>> Change-Id: Ie6bd28a898dab476abf34decb0eecc42122f17ce
>>> Signed-off-by: Sergiu Iordache<sergiu@chromium.org>
>>> ---
>>
>> the idea can be valid, but you have to add some check to set the
>> record size. It'd be better to add a lower and upper bound and to
>> check for it's power of two.
>
> That sounds like a good idea. Since the memory size gets rounded to a
> power of two it would probably be more consistent to round down the
> record size as well. This way you would be sure that mem_size is a
> multiple of record size as well. The upper bound would be the memory
> size, which is already checked. I'm not sure whether it would be a
> good idea to add lower bound different from record_size != 0 (I don't
> know why someone would need to dump 8 bytes for example but is there a
> reason to limit it?)
>
> Sergiu
>
I meant to use (as at the moment) min 4k for record size and so min 4k
for mem_size.
Marco
next prev parent reply other threads:[~2011-06-28 17:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 1:21 [PATCH 0/3] char drivers: ramoops improvements Sergiu Iordache
2011-06-28 1:21 ` [PATCH 1/3] char drivers: ramoops default platform device for module parameter use Sergiu Iordache
2011-06-28 17:56 ` Daniel Baluta
2011-06-28 1:21 ` [PATCH 2/3] char drivers: ramoops dump_oops platform data Sergiu Iordache
2011-06-28 6:30 ` Marco Stornelli
2011-06-28 1:21 ` [PATCH 3/3] char drivers: ramoops record_size module parameter Sergiu Iordache
2011-06-28 6:39 ` Marco Stornelli
2011-06-28 16:38 ` Sergiu Iordache
2011-06-28 17:17 ` Marco Stornelli [this message]
2011-06-28 6:27 ` [PATCH 0/3] char drivers: ramoops improvements 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=4E0A0C90.2010305@gmail.com \
--to=marco.stornelli@gmail.com \
--cc=Artem.Bityutskiy@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=darwish.07@gmail.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sergiu@google.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.