From: Toshi Kani <toshi.kani@hp.com>
To: Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>
Cc: horms@verge.net.au, kexec@lists.infradead.org
Subject: Re: [Patch v3] Add persistent memory support
Date: Mon, 24 Aug 2015 13:54:32 -0600 [thread overview]
Message-ID: <1440446072.14237.8.camel@hp.com> (raw)
In-Reply-To: <20150820074234.GA23537@localhost.localdomain>
On Thu, 2015-08-20 at 15:42 +0800, Dave Young wrote:
> On 08/20/15 at 10:52am, Baoquan He wrote:
> > On 08/20/15 at 10:38am, Dave Young wrote:
> > > On 08/19/15 at 06:45pm, Baoquan He wrote:
> > > > On 08/19/15 at 05:28pm, Dave Young wrote:
> > > > > Hi,
> > > > >
> > > > > On 08/19/15 at 05:03pm, Baoquan He wrote:
> > > >
> > > > > > diff --git a/kexec/arch/i386/crashdump-x86.c
> > > > > > b/kexec/arch/i386/crashdump-x86.c
> > > > > > index 82bf239..598a78f 100644
> > > > > > --- a/kexec/arch/i386/crashdump-x86.c
> > > > > > +++ b/kexec/arch/i386/crashdump-x86.c
> > > > > > @@ -301,6 +301,10 @@ static int get_crash_memory_ranges(struct
> > > > > > memory_range **range, int *ranges,
> > > > > > type = RANGE_ACPI;
> > > > > > } else if(memcmp(str,"ACPI Non-volatile
> > > > > > Storage\n",26) == 0 ) {
> > > > > > type = RANGE_ACPI_NVS;
> > > > > > + } else if(memcmp(str,"Persistent Memory
> > > > > > (legacy)\n",27) == 0 ) {
> > > > > > + type = RANGE_PRAM;
> > > > > > + } else if(memcmp(str,"Persistent Memory\n",18)
> > > > > > == 0 ) {
> > > > > > + type = RANGE_PMEM;
> > > > > > } else if(memcmp(str,"reserved\n",9) == 0 ) {
> > > > > > type = RANGE_RESERVED;
> > > > > > } else if (memcmp(str, "GART\n", 5) == 0) {
> > > > > > @@ -640,6 +644,8 @@ static void cmdline_add_memmap_internal(char
> > > > > > *cmdline, unsigned long startk,
> > > > > > strcat (str_mmap, "K$");
> > > > > > else if (type == RANGE_ACPI || type == RANGE_ACPI_NVS)
> > > > > > strcat (str_mmap, "K#");
> > > > > > + else if (type == RANGE_PRAM)
> > > > > > + strcat (str_mmap, "K!");
> > > > >
> > > > > Since we have switched to use e820 it is not necessary to
> > > > > supporting new things in legacy memmap interface?
> > > >
> > > > Well, I am not sure about this. Kexec-tools provides memmap method
> > > > to pass the memory ranges, then either we continue supporting it or
> > > > we delete it. Now is this OK we just keep legacy memmap code there
> > > > and ignore it? If people check the man page and find --pass-memmap
> > > > -cmdline and intend to try, then kexec/kdump fail, then how do we go
> > > > with it?
> > >
> > > It is a legacy interface, IMO we should deprecate it and remove it
> > > after a period like several release cycle.
> >
> > So if customers still want to specify memmap there isn't a way.
> >
>
> Why do one use memmap with new kexec-tools?
>
> There's no reason to use the old interface, I do not think there's any
> benefit since new interface works well and be more scalable.
Unless --pass-memmap-cmdline has already been deprecated, I think it should
keep up with the kernel update in the memmap cmd-line. IOW, if we do not
keep it up, it should be marked as deprecated.
Thanks,
-Toshi
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-08-24 19:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 9:03 [Patch v3] Add persistent memory support Baoquan He
2015-08-19 9:28 ` Dave Young
2015-08-19 10:45 ` Baoquan He
2015-08-20 2:38 ` Dave Young
2015-08-20 2:52 ` Baoquan He
2015-08-20 7:42 ` Dave Young
2015-08-24 19:54 ` Toshi Kani [this message]
2015-08-25 7:37 ` Dave Young
2015-09-02 1:04 ` Simon Horman
2015-09-23 8:33 ` Petr Tesarik
2015-09-23 9:16 ` Baoquan He
2015-09-23 9:23 ` 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=1440446072.14237.8.camel@hp.com \
--to=toshi.kani@hp.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
/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.