public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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