From: Dan Aloni <da-x@monatomic.org>
To: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: Determine version of kernel that produced vmcore
Date: Mon, 9 Jul 2007 14:41:31 +0300 [thread overview]
Message-ID: <20070709114131.GA18750@localdomain> (raw)
In-Reply-To: <20070709092154.GA19705@suse.de>
On Mon, Jul 09, 2007 at 11:21:54AM +0200, Bernhard Walle wrote:
> Hello,
>
> * Dan Aloni <da-x@monatomic.org> [2007-07-06 16:58]:
> >
> > Redhat has a makedumpinfo util which they intend to use as slim
> > kernel-version-independent utility on kdump rootfs in order to
> > save /proc/vmcore in a compact manner.
>
> I think you mean makedumpfile, don't you?
Yes, a typo, sorry.
> > A patch that I am working on will make it possible to integrate
> > the output of 'makedumpinfo -g' into vmlinux as the final build
> > stage of the kernel. This information will be presented itself
> > as /proc/kcore.info for the first kernel throughout its entire
> > execution.
>
> That sounds good. But I doubt that kernel developers like the idea of
> needing another utility in the build process ...
I don't think it would add much complexity to build process as it
is now, just like the other tools that transparently do post-linking
modifications. As far as the developer is concerned, there's just
the vmlinux and/or bzImage files that get emitted at the end.
> > Then inside initramfs of the first kernel, a small
> > util will modify the vmlinux file of the kdump kernel before it
> > gets loaded so that another special file appearing as
> > /proc/vmcore.info under the kdump kernel will present the same
> > info.
>
> Where do you get the info from? If you're in the kdump initrd,
> then the kdump kernel is already loaded. Do you want to attach the
> info from the crashed kernel to the initrd of the kdump kernel?
Not exactly. Let me describe the procedure in greater detail.
Basically, it would go like this:
1. <normal bootloader boot>
2. <normal initramfs>
3. embed_configfile /proc/kcore.info /vmlinux-kdump
4. kexec -l vmlinux-kdump <....>
5. <boot continues>
6. <crash>
7. <kdump kernel boot>
8. <kdump initramfs runs>
9. makedumpfile -i /proc/vmcore.info <....>
NOTES:
** in step 3 embed_configfile modifies vmlinux-kdump in place,
copying /proc/kcore.info into the data section of the vmlinux-kdump
at certain symbol (e.g. 'char core_info[0x1000]').
** in step 9 that data section variable (e.g. core_info) which was
originally holds the content of /proc/kcore.info is being presented
as /proc/vmcore.info for the util to use.
To complete the picture, at the final build stage of vmlinux we
would have this:
makedumpfile -g vmlinux.configfile -x vmlinuxx
embed_configfile vmlinux.configfile vmlinux
rm vmlinux.configfile
BTW I think there could be a confusion between makedumpfile's
CONFIGFILE and the .config file, so we should pick a different
name for it...
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
next prev parent reply other threads:[~2007-07-09 11:41 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-06 13:28 Determine version of kernel that produced vmcore Bernhard Walle
2007-07-06 14:58 ` Dan Aloni
2007-07-09 9:21 ` Bernhard Walle
2007-07-09 11:41 ` Dan Aloni [this message]
2007-07-09 20:49 ` Bernhard Walle
2007-07-10 4:45 ` Dan Aloni
2007-07-10 13:20 ` Bernhard Walle
2007-07-10 15:00 ` Vivek Goyal
2007-07-10 17:17 ` Neil Horman
2007-07-10 17:35 ` Dan Aloni
2007-07-10 18:26 ` Dan Aloni
2007-07-10 19:00 ` Neil Horman
2007-07-10 20:36 ` Dan Aloni
2007-07-11 11:57 ` Neil Horman
2007-07-10 6:48 ` Vivek Goyal
2007-07-10 8:14 ` Dan Aloni
2007-07-10 12:12 ` Neil Horman
2007-07-10 13:05 ` Bernhard Walle
2007-07-10 12:09 ` Neil Horman
2007-07-10 16:52 ` Dan Aloni
2007-07-11 6:07 ` Vivek Goyal
2007-07-11 7:32 ` Dan Aloni
2007-07-11 13:43 ` Ken'ichi Ohmichi
2007-07-13 3:58 ` Vivek Goyal
2007-07-13 7:49 ` Bernhard Walle
2007-07-13 3:43 ` Vivek Goyal
2007-07-11 8:58 ` Bernhard Walle
2007-07-10 3:13 ` Ken'ichi Ohmichi
2007-07-10 12:02 ` Neil Horman
2007-07-13 11:05 ` Ken'ichi Ohmichi
2007-07-13 13:15 ` Bernhard Walle
2007-07-16 4:19 ` Vivek Goyal
2007-07-16 11:57 ` Bernhard Walle
2007-07-16 12:25 ` Vivek Goyal
2007-07-16 12:27 ` Bernhard Walle
2007-07-16 12:28 ` Bernhard Walle
2007-07-16 12:36 ` Vivek Goyal
2007-07-18 14:07 ` Ken'ichi Ohmichi
2007-07-18 23:10 ` Bernhard Walle
2007-07-24 6:49 ` Ken'ichi Ohmichi
2007-07-19 14:12 ` Vivek Goyal
2007-07-19 16:39 ` Don Zickus
2007-07-19 16:49 ` Bernhard Walle
2007-07-19 16:59 ` Don Zickus
2007-07-23 5:01 ` Vivek Goyal
2007-07-23 11:47 ` Ken'ichi Ohmichi
2007-07-23 13:02 ` Dan Aloni
2007-07-23 15:58 ` Vivek Goyal
2007-07-24 6:40 ` Ken'ichi Ohmichi
2007-07-17 3:50 ` Vivek Goyal
2007-07-17 8:17 ` Bernhard Walle
2007-07-10 12:52 ` Bernhard Walle
2007-07-10 6:36 ` Vivek Goyal
2007-07-10 12:59 ` Bernhard Walle
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=20070709114131.GA18750@localdomain \
--to=da-x@monatomic.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.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