| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] kexec trouble
Hi again Gerd,
On 12/7/06, Gerd Hoffmann <kraxel@xxxxxxx> wrote:
Hi,
> Function pointers sound like the right way to go! Happy hacking!
First step of a cleanup by moving to function pointers.
As a first step I think they look pretty good. I have a few random comments.
Compile tested only.
Ok. I've browsed through the patches and done some basic compilation too.
First three attachments replace the patches with identical names in
patches/linux-2.6. The last should be applied to the sparse tree.
I think using a structure for all callbacks will result in cleaner
code. This is sort of a nitpick because it does not really matter
function wise, but it sounded earlier like you were aiming for
something that would be directly acceptable by the kexec and kdump
community. And I'm all for cleanliness.
Personally I would go with changing the code in kernel/kexec.c to
instead of calling machine_kexec() call kexec_ops.machine_kexec().
This regardless of the use of KEXEC_ARCH_USES_HOOKS. Then I would have
a single global instance of the structure kexec_ops declared in
kernel/kexec.c, and it would by default fill in
kexec_ops.machine_kexec() to machine_kexec. That way you won't have to
rename the arch-specific functions and there is no need to declare the
hooks in the arch-specific files. Maybe you won't need
KEXEC_ARCH_USES_HOOKS at all.
The load and unload code may be broken today if KEXEC_ARCH_USES_HOOKS
is unset - can you really check if machine_kexec_load is non-NULL if
it is inline?
The reason why I did put the page-macros in arch-specific header files
was because they need to be different on ia64. So your unification in
drivers/xen/core/machine_kexec.c may be ok for now (if our goal is x86
only), but in the future we need to figure out how to change them
nicely on ia64.
You probably remember that I was kind of negative to trying to solve
mainline merge issues at the same time as implementing this "switch".
This was because I remembered that paravirt allowed patching of inline
machine code. At least that's the impression I got from a presentation
given here in Tokyo by Rusty. I think the page macros ideally should
be patched in, but it's kind of hard trying to do that without
paravirt..
Finally, we should get rid of the #ifdef CONFIG_XEN left here and
there. My main concern is the code in crash.c which need to be
replaced with runtime checks if we are aiming for a single binary for
both native and dom0. I left out domU because it doesn't do crash,
right?
If you have an updated snapshot (or a replay saying I should use this
version) then I'll try out the code the first thing next week.
Thanks,
/ magnus
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home