lkml.org 
[lkml]   [2011]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kexec/kdump for Xen - implementation question
    On Wed, Jun 08, 2011 at 06:04:45PM +0200, Daniel Kiper wrote:
    > On Tue, Jun 07, 2011 at 11:29:26AM +0100, Ian Campbell wrote:
    > > On Mon, 2011-06-06 at 17:04 +0100, Daniel Kiper wrote:
    > > > Hi,
    > > >
    > > > Currently, I am working on kexec/kdump for Xen with emphasis on dom0
    > > > implementation issues. After reviewing relevant Xen Linux Kernel
    > > > Ver. 2.6.18 code I realized (as I expected) that original kexec/kdump
    > > > in mainline kernel should be extensively amended. Further, after some
    > > > discussion with Konrad Rzeszutek Wilk and Ian Campbell it was clear
    > > > for me that it could be done in a few diffrent ways. Due to this facts
    > > > I decided to establish general implementation details with LKML and
    > > > Xen-devel community to avoid extensive code rewrite in case my own
    > > > proposal would not be accepted.
    > > >
    > > > Now I think about four solutions. I will present them in order of my
    > > > preference. However, if you have another soultions to that problem
    > > > please drop me a line.
    > > >
    > > > 1) Currently existing kexec/kdump implementation should be amended
    > > > by adding Xen specific code mainly in arch/i386. It should look
    > > > like:
    > > >
    > > > void machine_kexec(struct kimage *image)
    > > > {
    > > > #ifdef CONFIG_XEN
    > > > if (xen_initial_domain()) {
    > > > ...
    > > > Xen specific code
    > > > ...
    > > > }
    > > > #endif
    > > >
    > > > ...
    > > > generic kexec/kdump code
    > > > ...
    > > > }
    > >
    > > This is about the ugliest way to do things and should be avoided.
    >
    > I think that in this case it is to some extent. I decided put
    > this solution before struct machine_kexec_ops solution because
    > this (let say conditional solution) touches only x86 code (and
    > if it be required IA-64). struct machine_kexec_ops proposal
    > require changes for 8 archs. I am not sure it could be accepted
    > by kexec/kdump and relevant archs maintainers quickly. However,

    Slowly is in general how LKML works with patches. Once you have
    an idea of how you want the callback/structs be set lets
    email the maintainer of the kexec to get his feedback. If he is OK
    then I don't think the different arch maintainers will care much
    (as long as it has been tested - and that can be done with QEMU).
    > I think that struct machine_kexec_ops is better as longterm
    > solution.

    Sounds like that is the winner then.


    \
     
     \ /
      Last update: 2011-06-09 17:03    [W:0.031 / U:1.392 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site