On 01/30/2013 08:39 AM, Thomas Renninger wrote:
This:
- heavily cleans up the unnecesary reserved memory passing via memmap=
- still provides a clean way of passing a valid e820 table through
boot structures (no Linux kernel made up e820 type passing)
- Keeps complexity as low as possible and at one place and does not
involve kexec-tools as another error source (passing a badly
mangled e820 table or not being able to consider stuff the kernel
can when mangeling).
If for some reason the e820 table in kdump case needs to be
touched again, I am pretty sure you do not want to look up
kexec-tools code.
Also you won't be able to fix/workaround things in kexec-tools
the way you can in the kernel.
Say what? The kernel is an open source tool, so is kexec, and a *lot*
of people have dependencies on specific kernel versions which does not
I also do not think it's a good idea to pass an unspecified,
Linux kernel made up e820 type through the public boot interface.
It's our interface. We specify it. On the other hand, we may want to
make these negative numbers rather than starting at 128 to avoid future
collisions with real memory types (not that they are growing very fast.)
So looking from the other side, passing a modified e820 table
only has disadvantages. The only advantage I can see that
memmap=..,X@Y,W@Z needs not to be passed. But this is rather
short and static now and not huge depending on the e820 reserved
entries from the BIOS (and still obvious where it comes from and why
it gets passed. Passing things hidden in a modified e820 boot structure
is not a good idea).
The command line is fundamentally a human-oriented interface and its
semantics change over time (considering the built-in command line stuff,
for example.) It is thus fragile.
The e820 map is fundamentally what you care about, and it has to be
passed correctly anyway -- or your changes are utterly broken. The
modifications that have to be performed (from RAM to KDUMP) is trivial.
I have to admit to being rather confused as to the separation of various
bits of kdump between the host kernel and various user-space components,
but the whole use of the command line to pass the memory map seems just
broken in light of everything that can go wrong.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
