>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.
I see, I think this description is better than the first one.
Now, makedumpfile can't get an appropriate values of the two macros since the
values are variable even if the architecture and the kernel version are fixed
(at least for arm), and we can't solve this without *manual code fixing*, right?
In practice, the current code expects that all arm machines adopt Exynos
processors, this is an problem definitely.
#ifdef __arm__
#define KVBASE_MASK (0xffff)
#define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK)
#define _SECTION_SIZE_BITS (28)
#define _MAX_PHYSMEM_BITS (32)
I think it's better to fix the descriptions to get acceptability,
but this patch is necessary from the view point of makedumpfile.
So I recommend you to repost this patch set, then I'll accept it.
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 at huawei.com>
>>> ---
>>> 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
>>
>> .
>>
>
