All of lore.kernel.org
 help / color / mirror / Atom feed
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Baoquan He <bhe@redhat.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
	"chaowang@redhat.com" <chaowang@redhat.com>
Subject: Re: [PATCH v2] makedumpfile: add parameters to update_cyclic_region
Date: Wed, 27 Nov 2013 16:37:55 +0900	[thread overview]
Message-ID: <5295A153.8080400@jp.fujitsu.com> (raw)
In-Reply-To: <20131127053731.GA4318@dhcp-16-252.nay.redhat.com>

(2013/11/27 14:37), Baoquan He wrote:
> On 11/26/13 at 03:12am, Atsushi Kumagai wrote:
>> Hello Baoquan,
>>
>> On 2013/11/26 11:53:34, kexec <kexec-bounces@lists.infradead.org> wrote:
>>> On 11/25/13 at 01:33pm, HATAYAMA Daisuke wrote:
>>>> (2013/11/25 11:31), Baoquan He wrote:
>>>>> Hi HATAYAMA and Atsushi,
>>>>>
>>>>> I think v2 is better than v1, since update_cyclic_region can be used
>>>>> with a more flexible calling.
>>>>>
>>>>> What's your opinion about this?
>>>>>
>>>>> On 11/23/13 at 05:29pm, Baoquan He wrote:
>>>>
>>>> Thanks for your patch. The bug is caused by my patch set for creating a
>>>> whole part of 1st bitmap before entering cyclic process.
>>>>
>>>> I think v1 is better than v2. The update_cyclic_range() call relevant
>>>> to this regression is somewhat special compared to other calls; it is
>>>> the almost only call that doesn't need to perform filtering processing.
>>>> To fix this bug, please make the patch so as not to affect the other calls,
>>>> in order to keep change as small as possible.
>>>
>>> OK, if you think so. But I still think update_cyclic_region is a little
>>> weird, its name doesn't match its functionality, this confuses code
>>> reviewers. And it does something unnecessary somewhere. If it's
>>> possible, I would rather take out the create_1st_bitmap_cyclic and
>>> exclude_unnecessary_pages_cyclic, and call them explicitly where they
>>> are really needed. Surely we can make a little change in both of them,
>>> E.g add a parameter pfn to them, then we can also judge like
>>> update_cyclic_region has done:
>>>
>>>          if (is_cyclic_region(pfn))
>>>                  return TRUE;
>>>
>>> If you insist on v1 is a better idea, I will repost based on it, but keep
>>> my personal opinion.
>>
>> I also prefer v1 because the usage of update_cyclic_region_without_exclude() is
>> definite and understandable while v2's update_cyclic_region() is complicated.
>>
>> On the other hand, I agree with your opinion, so could you post a cleanup patch
>> separately from v1 patch ?
>
> Hi Atsushi,
>
> Yeah, you are right, v1 is better. Then we can wait for HATAYAMA's cleanup
> patch. I know you are goint to release v1.5.5.
>

I don't have a time to make a clean-up patch now, at least within this year.

-- 
Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2013-11-27  7:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22 12:07 [PATCH] makedumpfile: add a new function update_cyclic_region_without_exclude for partial_bitmap1 setting Baoquan He
2013-11-23  9:29 ` [PATCH v2] makedumpfile: add parameters to update_cyclic_region Baoquan He
2013-11-25  2:31   ` Baoquan He
2013-11-25  4:33     ` HATAYAMA Daisuke
2013-11-26  2:52       ` Baoquan He
2013-11-26  3:12         ` Atsushi Kumagai
2013-11-27  5:37           ` Baoquan He
2013-11-27  7:37             ` HATAYAMA Daisuke [this message]
2013-12-02  8:43               ` Baoquan He
2013-11-26  5:50         ` HATAYAMA Daisuke
2013-11-26  7:57           ` Baoquan He
2013-11-26  8:50             ` HATAYAMA Daisuke
2013-11-26 10:24               ` Baoquan He
2013-11-26 11:59               ` Baoquan He

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=5295A153.8080400@jp.fujitsu.com \
    --to=d.hatayama@jp.fujitsu.com \
    --cc=bhe@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=kumagai-atsushi@mxc.nes.nec.co.jp \
    /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.