From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756213AbXGWFBj (ORCPT ); Mon, 23 Jul 2007 01:01:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752521AbXGWFBd (ORCPT ); Mon, 23 Jul 2007 01:01:33 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:35697 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751912AbXGWFBc (ORCPT ); Mon, 23 Jul 2007 01:01:32 -0400 Date: Mon, 23 Jul 2007 10:31:47 +0530 From: Vivek Goyal To: Don Zickus Cc: "Ken'ichi Ohmichi" , Neil Horman , Bernhard Walle , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Dan Aloni Subject: Re: Determine version of kernel that produced vmcore Message-ID: <20070723050147.GA5691@in.ibm.com> Reply-To: vgoyal@in.ibm.com References: <20070716123633.GA10920@in.ibm.com> <20070718230740oomichi@mail.jp.nec.com> <20070719163915.GN9623@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070719163915.GN9623@redhat.com> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote: [..] > > 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. > That's a good point Don. kernel rpm being dependent on kexec-tools rpm is not a good idea. > 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?). > I am also in favour of a complete kernel based solution. Export required info from kernel and let kexec-tools parse that info, pass it to second kernel and it will be appended to vmcore. This will put some restrictions on that we can't keep on changing the format of the info very frequently and some new features might not work with older kernels. But I guess, kexec-tools can provide an override option where dump filtering info can be passed on kexec-tools command line (as suggested by ken'chi). If user passes this info on command line then kexec-tools will not read the info exported from kernel. This way new features can be made to work on older kernels. Thanks Vivek