[libvirt] [PATCHv7 09/18] util: Add more interfaces for resctrl monitor

[Huaqiang,Wang]

On 2018年11月05日 23:10, John Ferlan wrote:
>
> On 10/22/18 4:01 AM, Wang Huaqiang wrote:
>> Add interfaces monitor group to support operations such
>> as add PID, set ID, remove group ... etc.
>>
>> Signed-off-by: Wang Huaqiang <huaqiang.wang at intel.com>
>> ---
>>   src/libvirt_private.syms |  5 +++++
>>   src/util/virresctrl.c    | 47 +++++++++++++++++++++++++++++++++++++++++++++++
>>   src/util/virresctrl.h    | 14 ++++++++++++++
>>   3 files changed, 66 insertions(+)
>>
> [...]
>
>> +int
>> +virResctrlMonitorRemove(virResctrlMonitorPtr monitor)
>> +{
>> +    int ret = 0;
>> +
>> +    if (!monitor->path)
>> +        return 0;
> Similar to patch1 - if we are using a default path, then we don't want
> to removed even if it exists, so I *think* (but you need to confirm for
> me) that the following should be done:
>
>      if (STREQ(monitor->path, monitor->alloc->path))
>          return 0;
>
> Although I wonder if a !monitor->alloc guard should be used as well.
> Whether it's part of a || !monitor->path return 0 or this check should
> be "if (monitor->alloc && STREQ(...))"... Thoughts?

You are right, I should do the similar things that have done for removal 
of allocation.
otherwise the allocation directory will be removed in removing monitor 
group.
I did not find these, because the removal of allocation is just after 
removal of
all monitor groups.

@monitor->alloc and @monitor->path should not be NULL here, so following
changes would be fine.

     if (STREQ(monitor->path, monitor->alloc->path))
         return 0;

Thanks

>
>> +
>> +    VIR_DEBUG("Removing resctrl monitor%s", monitor->path);
> s/monitor%s/monitor path='%s'

OK. Thanks.

>
>> +    if (rmdir(monitor->path) != 0 && errno != ENOENT) {
>> +        ret = -errno;
>> +        VIR_ERROR(_("Unable to remove %s (%d)"), monitor->path, errno);
>> +    }
>> +
>> +    return ret;
>> +}
> I can make the changes - just let me know your preferred way to proceed...
>
> Reviewed-by: John Ferlan <jferlan at redhat.com>
>
> John

Thanks for the review.
Huaqiang

> [...]