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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox