>>> On 09.05.17 at 12:21, <george.dun...@citrix.com> wrote:
> On 09/05/17 11:08, Jan Beulich wrote:
>>>>> On 09.05.17 at 11:44, <george.dun...@citrix.com> wrote:
>>> On 09/05/17 22:22, Xiong Zhang wrote:
>>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>>> +++ b/xen/arch/x86/mm/p2m-ept.c
>>>> @@ -502,7 +502,7 @@ static int ept_invalidate_emt_range(struct p2m_domain
> *p2m,
>>>> * - zero if no adjustment was done,
>>>> * - a positive value if at least one adjustment was done.
>>>> */
>>>> -static int resolve_misconfig(struct p2m_domain *p2m, unsigned long gfn)
>>>> +static int ept_resolve_misconfig(struct p2m_domain *p2m, unsigned long
>>>> gfn)
>>>
>>> I think while we're renaming this I'd rename this to ept_do_recalc().
>>
>> Which gets me to ask (once again) what purpose the ept_ prefix
>> has for a static function. I'd rather see this called do_recalc(), and
>> the p2m-pt variant could be left unchanged altogether.
>
> Well we should have them both named do_recalc() (no prefix), or have
> them both tagged to specify which version they're for. ISTR people
> complaining about duplicate static symbols making things harder to debug
> (i.e., is this do_recalc() in the stack trace the p2m-pt version or the
> p2m-ept version?), so the latter is probably preferable.
But that's the reason I had done d37d63d4b5 ("symbols: prefix static
symbols with their source file names") - they are distinguishable in
stack traces nowadays.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
