Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

From: Eric W. Biederman
Date: Fri Feb 04 2005 - 07:06:57 EST


ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes:

> Hirokazu Takahashi <taka@xxxxxxxxxxxxx> writes:
> > > Most of this just results in easier management between the pieces.
> > > Which is a good thing. However at the moment I don't think it
> > > simplifies any of the core problems. I still need to reserve
> > > a large hunk of physical address space early on before any
> > > DMA transactions are setup to hold the new kernel.
> >
> > I agree that my idea is not essential at the moment.
> >
> > > So while I am happy to see patches that improve this I don't
> > > actually care right now.
> >
> > ok.

Thinking about this some more this does have a significant aspect
on the design. For architectures that support this, on the
primary kernel the command line option becomes:
crashkernel=size instead of crashkernel=size@location.
Which means the kernel needs to call alloc_bootmem instead
of reserve_bootmem. So it results in a primary kernel implementation
difference.

In addition if we really can push all of the dump specific
functionality into user space as it appears we can, this allows a
generic kernel to be used for the crash dump process. It will
probably still be a special hardened build where reliability is
more important than performance. So that any micro hit we take in
performance by modifying __pa() and __va() will be irrelevant.

I like it.

I have already demonstrated that there is a general technique that
any architecture can use to build a kernel that runs at a non-default
address. So for the architectures that cannot build a PIC kernel
there is still a proven solution available, it simply will not
be as nice to manage.

x86_64 should pretty straight forward. i386 will be a little more
difficult but doable.

Patches are still welcome.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/