[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] memory: Display MemoryRegion name in read/write ops trace ev
From: |
Laurent Vivier |
Subject: |
Re: [PATCH] memory: Display MemoryRegion name in read/write ops trace events |
Date: |
Mon, 21 Jun 2021 12:13:39 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
Le 21/06/2021 à 12:08, Philippe Mathieu-Daudé a écrit :
> Hi Laurent,
>
> On 6/7/21 1:29 PM, Laurent Vivier wrote:
>> Le 07/06/2021 à 10:28, Philippe Mathieu-Daudé a écrit :
>>> On 6/7/21 9:33 AM, Laurent Vivier wrote:
>>>> Le 02/06/2021 à 12:49, Philippe Mathieu-Daudé a écrit :
>>>>> Cc'ing qemu-trivial@
>>>>>
>>>>> On 3/18/21 4:39 PM, Philippe Mathieu-Daudé wrote:
>>>>>> ping?
>>>>>>
>>>>>> On 3/7/21 8:48 AM, Philippe Mathieu-Daudé wrote:
>>>>>>> MemoryRegion names is cached on first call to memory_region_name(),
>>>>
>>>> It is cached on first call but now that it is used in the trace function,
>>>> does it mean it will be
>>>> always allocated in memory?
>>>
>>> Yes, this is how memory_region_name() works:
>>>
>>> const char *memory_region_name(const MemoryRegion *mr)
>>> {
>>> if (!mr->name) {
>>> ((MemoryRegion *)mr)->name =
>>> g_strdup(object_get_canonical_path_component(OBJECT(mr)));
>>> }
>>> return mr->name;
>>> }
>>
>> OK, in fact I didn't see it was called from inside a "if
>> (trace_event_get_state_backends(TRACE_MEMORY_REGION_OPS_XXX))" and was
>> worrying about the memory for
>> the string always allocated.
>>
>> So it looks good.
>
> Is there something else you expect me to do with this patch?
> Maybe you expect another R-b to take it, so I should keep
> pinging for review?
>
No, I'm working on a linux-user pull request, once done I'll do a new trivial
branch pull request.
Thanks,
Laurent