Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore

[Liu hua]

On 2014/5/13 14:21, Atsushi Kumagai wrote:
> Hello Liu,
> 
>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as
>> macros. So if we deal with vmcores with different values
>> of these two macros. We have to recompile makedumpfile.
> 
> There are other macros which have architecture-specific values
> (e.g. __PAGE_OFFSET), and some functions are specific to each
> architecture (e.g. vaddr_to_paddr()), so we need recompilation
> eventually.
> 
> OTOH, we already don't need recompilation for the same architecture
> since the values of such macros are defined for each kernel version
> like below:
> 
> #ifdef __x86_64__
> ...
> #define _MAX_PHYSMEM_BITS_ORIG          (40)
> #define _MAX_PHYSMEM_BITS_2_6_26        (44)
> #define _MAX_PHYSMEM_BITS_2_6_31        (46)
> 
> So I don't think this patch is valuable.

Hi Atsushi,

For x86, it is not necessory. But for arm, different venders
may define different SECTION_SIZE_BITS. for example:

   1 arch/arm/mach-clps711x/include/mach/memory.h
     #define SECTION_SIZE_BITS 24
   2 arch/arm/mach-exynos/include/mach/memory.h
     #define SECTION_SIZE_BITS 28
   4 arch/arm/mach-hisi/include/mach/memory.h
     #define SECTION_SIZE_BITS 26
   8 arch/arm/mach-sa1100/include/mach/memory.h
     #define SECTION_SIZE_BITS 27

Perhaps we should find another way to let the userspace tools
to get the architecture-specific values.

Liu Hua

> 
> 
> Thanks
> Atsushi Kumagai
> 
>> This patch makes makedumpfile get these two values from
>> vmcore info, if existing. It makes the makedumpfile more
>> compatible to vmcores with different section size.
>>
>> Signed-off-by: Liu Hua <sdu.liu@xxxxxxxxxx>
>> ---
>> makedumpfile.c | 17 +++++++++++++++++
>> makedumpfile.h |  2 ++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/makedumpfile.c b/makedumpfile.c
>> index 6cf6e24..3cdf323 100644
>> --- a/makedumpfile.c
>> +++ b/makedumpfile.c
>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void)
>> 	READ_NUMBER("PG_slab", PG_slab);
>> 	READ_NUMBER("PG_buddy", PG_buddy);
>> 	READ_NUMBER("PG_hwpoison", PG_hwpoison);
>> +	READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS);
>> +	READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS);
>>
>> 	READ_SRCFILE("pud_t", pud_t);
>>
>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void)
>> }
>>
>> int
>> +calibrate_machdep_info(void)
>> +{
>> +	if (NUMBER(MAX_PHYSMEM_BITS) > 0)
>> +		info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
>> +
>> +	if (NUMBER(SECTION_SIZE_BITS) > 0)
>> +		info->section_size_bits = NUMBER(SECTION_SIZE_BITS);
>> +
>> +	return TRUE;
>> +}
>> +
>> +int
>> initial(void)
>> {
>> 	off_t offset;
>> @@ -3214,6 +3228,9 @@ out:
>> 	if (debug_info && !get_machdep_info())
>> 		return FALSE;
>>
>> +	if (debug_info && !calibrate_machdep_info())
>> +		return FALSE;
>> +
>> 	if (is_xen_memory() && !get_dom0_mapnr())
>> 		return FALSE;
>>
>> diff --git a/makedumpfile.h b/makedumpfile.h
>> index eb03688..7acb23a 100644
>> --- a/makedumpfile.h
>> +++ b/makedumpfile.h
>> @@ -1434,6 +1434,8 @@ struct number_table {
>> 	long    PG_hwpoison;
>>
>> 	long	PAGE_BUDDY_MAPCOUNT_VALUE;
>> +	long	SECTION_SIZE_BITS;
>> +	long	MAX_PHYSMEM_BITS;
>> };
>>
>> struct srcfile_table {
>> --
>> 1.9.0
> 
> .
> 


--
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/