I'm posting this as an RFC mainly because I'm not sure how to model
the new API. This patches introduce a new naive API that will change
only the APPID and nothing else.
Currently there are no other known features related to Fibre Channel
resources so this non-extendable API will be sufficient, however the
appid lives in <resource> element in the XML where we currently have
root cgroup partition. Even though changing the partition will not be
supported and we don't know about anything else that could be placed
here it doesn't mean it will not happen in the future. In that case
we would have to add new API as well.
So I'm wondering if we should create a more generic API that would take
typed parameters as arguments:
int virDomainSetResource(virDomainPtr domain,
virTypedParameterPtr params,
int nparams,
unsigned int flags)
Any ideas?
Pavel Hrdina (7):
conf: extract appid validation to virDomainDefResourceAppidValidate
cgroup: extract setting fibre channel appid into virCgroupSetFCAppid
virCgroupSetFCAppid: properly handle when appid is NULL
src: introduce virDomainSetFibreChannelAppid API
remote: add RPC support for the virDomainSetFibreChannelAppid API
qemu: implement virDomainSetFibreChannelAppid API
tools: introduce virsh setappid command
docs/manpages/virsh.rst | 14 ++++++
include/libvirt/libvirt-domain.h | 4 ++
src/conf/domain_validate.c | 42 ++++++++++--------
src/conf/domain_validate.h | 2 +
src/driver-hypervisor.h | 6 +++
src/libvirt-domain.c | 44 +++++++++++++++++++
src/libvirt_private.syms | 2 +
src/libvirt_public.syms | 1 +
src/qemu/qemu_cgroup.c | 17 +-------
src/qemu/qemu_driver.c | 75 ++++++++++++++++++++++++++++++++
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 14 +++++-
src/remote_protocol-structs | 6 +++
src/util/vircgroup.c | 24 ++++++++++
src/util/vircgroup.h | 3 ++
tools/virsh-domain.c | 65 +++++++++++++++++++++++++++
16 files changed, 286 insertions(+), 34 deletions(-)
--
2.31.1
