From: Dave Young <dyoung@redhat.com>
To: Baoquan He <bhe@redhat.com>
Cc: toshi.kani@hp.com, horms@verge.net.au, kexec@lists.infradead.org
Subject: Re: [Patch v3] Add persistent memory support
Date: Thu, 20 Aug 2015 15:42:34 +0800 [thread overview]
Message-ID: <20150820074234.GA23537@localhost.localdomain> (raw)
In-Reply-To: <20150820025222.GH19950@dhcp-128-28.nay.redhat.com>
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.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-08-20 7:43 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 [this message]
2015-08-24 19:54 ` Toshi Kani
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=20150820074234.GA23537@localhost.localdomain \
--to=dyoung@redhat.com \
--cc=bhe@redhat.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=toshi.kani@hp.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.