From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: x86@kernel.org, kexec@lists.infradead.org,
Simon Horman <horms@verge.net.au>,
yinghai@kernel.org, Thomas Renninger <trenn@suse.de>,
vgoyal@redhat.com
Subject: Re: [PATCH 0/3] Cleanup kdump memmap= passing and e820 usage
Date: Wed, 30 Jan 2013 14:41:43 -0800 [thread overview]
Message-ID: <5109A1A7.1040609@zytor.com> (raw)
In-Reply-To: <87ehh2l2z3.fsf@xmission.com>
On 01/30/2013 02:29 PM, Eric W. Biederman wrote:
>>
>>> I think I would prefer that to call that new type RESERVED_MEM or
>>> RESERVED_CACHABLE. Being more specific is fine but dumpable certainly
>>> doesn't bring to mind what we are saying. Especially since we already
>>> communicate which areas were memory to the last kernel in an
>>> architecture generic format.
>>
>> I was thinking that marking them differently might help debugging, at
>> least, but yes, we can have a RESERVED_MEM type.
>>
>> However, Thomas does have a point that the current use of fairly small
>> positive values for Linux-defined types is a bad idea. We should use
>> negative types, or at least something north of 0x40000000 or so.
>
> Yes. It doesn't much matter in the kernel but when it because part of
> the ABI it is a real issue.
>
> Since old kernels treat any value they don't understand as reserved
> passing a modified e820 map seems reasonable to me once we have reserved
> a special linux value for it.
>
Just to prevent the possible funnies (including collisions with -errno)
that might be caused by negative numbers, I suggest we assign
Linux-specific values starting at some huge but still positive value
like 2000000000 -- that way we avoid any possible uses of negative errno
values internally in the kernel.
The bigger question is if we need a separate value from the current
E820_RESERVED_KERN. Since it is always easier to have multiple values
with the same semantics than it is to have too few, I would still prefer
we added a new E820_RESERVED_KDUMP, which would then be 2000000001.
What do you think?
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-01-30 22:41 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 15:02 [PATCH 0/3] Make use of new memmap= kernel parameter syntax Thomas Renninger
2013-01-22 15:02 ` [PATCH 1/3] kexec: Split kernel_version() to also be able to pass a release string Thomas Renninger
2013-01-22 15:02 ` [PATCH 2/3] kexec x86: Extract kernel version and convert it to KERNEL_VERSION() style Thomas Renninger
2013-01-22 15:02 ` [PATCH 3/3] kexec x86: Make kexec aware of new memmap= kernel parameter possibilities Thomas Renninger
2013-01-30 4:31 ` [PATCH 0/3] Make use of new memmap= kernel parameter syntax Simon Horman
2013-01-30 5:40 ` H. Peter Anvin
2013-01-30 5:52 ` Simon Horman
2013-01-30 16:03 ` Thomas Renninger
2013-01-30 16:06 ` [PATCH 1/3] x86 e820: Check for exactmap appearance when parsing first memmap option Thomas Renninger
2013-01-30 16:09 ` H. Peter Anvin
2013-01-30 16:08 ` [PATCH 2/3] x86: Introduce Linux kernel specific E820_RESERVED_KDUMP e820 memory range type Thomas Renninger
2013-01-30 16:10 ` [PATCH 3/3] x86 e820: Introduce memmap=kdump_reserve_usable for kdump usage Thomas Renninger
2013-01-30 16:10 ` [PATCH 0/3] Make use of new memmap= kernel parameter syntax H. Peter Anvin
2013-01-30 16:13 ` [PATCH 0/3] Cleanup kdump memmap= passing and e820 usage Thomas Renninger
2013-01-30 16:16 ` H. Peter Anvin
2013-01-30 16:39 ` Thomas Renninger
2013-01-30 16:52 ` H. Peter Anvin
2013-01-30 17:41 ` Yinghai Lu
2013-01-30 18:52 ` Eric W. Biederman
2013-01-30 21:38 ` H. Peter Anvin
2013-01-30 21:57 ` Eric W. Biederman
2013-01-30 22:10 ` H. Peter Anvin
2013-01-30 22:29 ` Eric W. Biederman
2013-01-30 22:41 ` H. Peter Anvin [this message]
2013-01-30 22:49 ` Yinghai Lu
2013-01-31 0:15 ` Thomas Renninger
2013-01-31 0:18 ` H. Peter Anvin
2013-01-31 9:11 ` Thomas Renninger
2013-02-06 15:23 ` Thomas Renninger
2013-02-06 23:04 ` Eric W. Biederman
2013-02-06 23:11 ` H. Peter Anvin
2013-02-06 23:39 ` Eric W. Biederman
2013-02-08 20:08 ` Thomas Renninger
2013-02-08 20:25 ` Eric W. Biederman
2013-02-08 20:56 ` Thomas Renninger
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=5109A1A7.1040609@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=trenn@suse.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox