[libvirt] [PATCHv7 09/18] util: Add more interfaces for resctrl monitor
Huaqiang,Wang
huaqiang.wang at intel.com
Tue Nov 6 09:04:38 UTC 2018
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
> [...]
More information about the libvir-list
mailing list