From: Don Zickus <dzickus@redhat.com>
To: "Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>
Cc: vgoyal@in.ibm.com, Neil Horman <nhorman@redhat.com>,
Bernhard Walle <bwalle@suse.de>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Dan Aloni <da-x@monatomic.org>
Subject: Re: Determine version of kernel that produced vmcore
Date: Thu, 19 Jul 2007 12:39:15 -0400 [thread overview]
Message-ID: <20070719163915.GN9623@redhat.com> (raw)
In-Reply-To: <20070718230740oomichi@mail.jp.nec.com>
On Wed, Jul 18, 2007 at 11:07:40PM +0900, Ken'ichi Ohmichi wrote:
> The content of mkdfinfo file has been increasing whenever adding
> features and correcting bugs. The content is increasing even now.
> And, the feature addition is done not only for new kernels but also
> for old upstream kernels. When the content of mkdfinfo file is taken
> into the kernel and fixed, the feature addition in the future is
> remarkably limited. So makedumpfile needs mkdfinfo file outside of
> the kernel.
>
> I propose the solution including Dan's, Vivek's and Bernhard's opinions.
> How about the following sequence for distributors ?
> (It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
> A new option "--mkdfinfo" is added to kexec command.)
>
> * On the kernel building system
> 1. Create the kernel files.
> # cd linux-2.6.xx
> # make
> 2. Create the mkdfinfo file from the vmlinux.
> # makedumpfile -g mkdfinfo-2.6.xx -x vmlinux
I am not a big fan of this approach as it forces distros to require
kexec-tools when building a kernel. Even Joe Hacker who wants a custom
kernel (and not interested in kexec) would have to not only download the
kernel.src.rpm but kexec-tools just to build a kernel that probably
doesn't have kexec enabled.
I had to deal with a similar experience when providing a build dependency
on the unifdef package when create the kernel-headers rpm for RHEL-5. A
lot of people were confused and upset by this dependency. Luckily
upstream resolved this by just putting similar code in the kernel/scripts
directory and thus removing the dependency (well not for RHEL-5). I would
rather not have to deal with this again unless I know there is a more
permanent solution that would remove this dependency.
After talking to Dave Anderson about this more, I start to understand why
Ken'ichi prefers to implement the new features in userspace instead of the
kernel (it makes things automatically work with older kernels), but I
still am not a big fan of it. I was hoping for a complete in kernel
solution (that way you never need the vmlinux file). Perhaps makedumpfile
can support both vmlinux files (if provided) or interface with the kernel
(if the vmlinux is not provided?).
Just my input. I might as well argue with Ken'ichi here than the
bugzilla. :-)
Cheers,
Don
next prev parent reply other threads:[~2007-07-19 16:46 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
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 [this message]
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=20070719163915.GN9623@redhat.com \
--to=dzickus@redhat.com \
--cc=bwalle@suse.de \
--cc=da-x@monatomic.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=oomichi@mxs.nes.nec.co.jp \
--cc=vgoyal@in.ibm.com \
/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