Suzuki-San,
>>> + for (; tmp->name!= NULL; tmp++)
>>> + if (!strcmp(tmp->name, platform))
>>> + return tmp;
>>
>> Is there any reasons to distinct "ppc440gp"?
>>
> No specific reasons, apart from just the name difference.
>
>> Since I see that there are no "ppc440" prefix platform other than PPC40
>> in latest cpu_specs[], and all of ppc440gp's values in ppc_boards[] are the
>> same as ppc440.
>> Can it be summarized by using STRNEQ("ppc440") or strncmp("ppc440")?
> The problem is, this is generic code. And there could be a different platforms
> which start with the same prefix and having different settings for the page
> bits, (e.g, freescale processors). So generalizing this would be a problem.
I can understand your careful thought, thanks.
> One option I could think of is defining a function rather than a 'name' for each
> platform to identify the 'running platform' as its variant.
>
> i.e,
>
> struct platform {
> int (*check_platform) (char *s);
> const char *name;
> ...
> }
>
> Where we could invoke the check_platform() for each platform, instead of
> doing a check ourselves. The check_platform() could be implemented by each
> distinct platforms and could use one board definition for multiple platform
> values. This would also help us to reduce the 'platform' definitions as different
> non-related platforms may also have the same set of definitions.
>
> So the loop would look like :
>
> for (; tmp->name!= NULL; tmp++)
> if (tmpe->check_platform(platform))
> return tmp;
>
> What do you think about this approach ?
I can imagine that ppc_boards[] own least entries "default", "ppc440", "ppc??",
(or declare as "ibm", "freescale", ..)
and call check_ppc440_platform("platform"), check_ppc??_platform("platform")
to check or update page bits.
The check_ppc440_platform() can do with SRTEQ("platform", "ppc440(gp)") easily
but check_ppc??_platform() has to check more conditions if prefixed name
has different settings for the page bits.
Finaly check_platform sometimes update page talbe bit members in struct platform.
This is interesting so I wait for your updates
even though my imagination is different from yours.
Thanks,
Toshi
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
