Message-Id: <20070713200533oomichi@mail.jp.nec.com>
Date:	Fri, 13 Jul 2007 20:05:33 +0900
From:	"Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp>
To:	Neil Horman <nhorman@...hat.com>
Cc:	Bernhard Walle <bwalle@...e.de>, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: Determine version of kernel that produced vmcore


Hi all,

2007/07/10 08:02:43 -0400, Neil Horman <nhorman@...hat.com> wrote:
>> Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors.
>> In the kernel building process, distributors need to make CONFIGFILE
>> on an older kernel (ex. RHEL5 kernel is built on RHEL4), and OSRELEASE
>> may be an older kernel. So OSRELEASE should be modified to the building
>> kernel version by hand, but it is not smart.
>> 
>> To solve this problem, I'm proposing 2 plans.
>> Could you give me your opinion ?
>> 
>> Plan 1:
>>   A new option [--osrelease="string"] is added.
>>   The OSRELEASE of CONFIGFILE is overwritten by "string".
>>   In the kernel building process, distributors should specify "string"
>>   as the building kernel version.
>> 
>> Plan2:
>>   Remove the OSRELEASE from CONFIGFILE.
>>   Instead of checking the OSRELEASE, makedumpfile only checks whether the
>>   area of /proc/vmcore specified by the symbol "system_utsname" in CONFIGFILE
>>   is the string "2.6.". If CONFIGFILE and /proc/vmcore don't match, the
>>   "system_utsname" must not point to the correct area in most cases.
>>   Old makedumpfile needs OSRELEASE, and it cannot work by new CONFIGFILE.
>>   But I think there are not any problems because old makedumpfile will not
>>   read new CONFIGFILE. Now, CONFIGFILE is used only by RHEL5's kdump initramfs,
>>   the CONFIGFILE is generated during 1st-kernel running. Even if CONFIGFILE
>>   will be updated, makedumpfile can read the CONFIGFILE because makedumpfile
>>   should be updated with CONFIGFILE.
>> 
>> 
>> I'd like to change the name of CONFIGFILE to mkdfinfo.
>> 
>Why not, instead of either plan above, just redefine OSRELEASE to be the version
>of the kernel the config file was built against?  i.e. when you build a config
>file, you need to specify a kernel to extract symbol information from, why not
>grab the utsname from that kernel and use that to set OSRELEASE?  When you're
>building a config file the running kernel on the system isn't really relevent
>anyway.

Did you say "makedumpfile should get OSRELEASE from a vmlinux file,
and output it to a mkdfinfo file", right ?
If so, you are right. I'm creating the patch for it.

BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
While 2nd-kernel is running, new makedumpfile comes to consider
2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
from a mkdfinfo file.

In current implementation, makedumpfile considers 2nd-kernel PAGESIZE
as 1st-kernel PAGESIZE if a vmlinux file is specified instead of a
mkdfinfo file. On the other hand, makedumpfile can get 1st-kernel
PAGESIZE correctly if a mkdfinfo file is specified, because there
is the rule that a mkdfinfo file should be generated on 1st-kernel.

Now, I will change this rule for generating a mkdfinfo file on the
kernel-building environment. I feel considering 2nd-kernel PAGESIZE
as 1st-kernel PAGESIZE is better than considering the PAGESIZE of
kernel-building environment, because 1st-kernel and 2nd-kernel have
the same PAGESIZE in most cases such as relocatable kernel.


Please let me know your opinion.


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

Powered by blists - more mailing lists