
On 08/09/2012 09:20 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
The virtlockd daemon will be responsible for managing locks on virtual machines. Communication will be via the standard RPC infrastructure. This provides the XDR protocol definition
* src/locking/lock_protocol.x: Wire protocol for virtlockd * src/Makefile.am: Include lock_protocol.[ch] in virtlockd
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- .gitignore | 1 + cfg.mk | 3 ++ src/Makefile.am | 14 ++++++- src/locking/lock_protocol.x | 89 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 src/locking/lock_protocol.x
Incomplete: squash this in so that we also use 'pdwtags' to ensure on-the-wire compatibility: diff --git c/src/Makefile.am i/src/Makefile.am index 30a5b42..ab228a5 100644 --- c/src/Makefile.am +++ i/src/Makefile.am @@ -278,7 +278,7 @@ EXTRA_DIST += $(REMOTE_DRIVER_PROTOCOL) \ # The alternation of the following regexps matches both cases. r1 = /\* \d+ \*/ r2 = /\* <[[:xdigit:]]+> \S+:\d+ \*/ -struct_prefix = (remote_|qemu_|virNet|keepalive_) +struct_prefix = (remote_|qemu_|virNet|keepalive_|virLockSpace) PDWTAGS = \ $(AM_V_GEN)if (pdwtags --help) > /dev/null 2>&1; then \ @@ -326,7 +326,9 @@ PROTOCOL_STRUCTS = \ $(srcdir)/remote_protocol-structs \ $(srcdir)/qemu_protocol-structs \ $(srcdir)/virnetprotocol-structs \ - $(srcdir)/virkeepaliveprotocol-structs + $(srcdir)/virkeepaliveprotocol-structs \ + $(srcdir)/lock_protocol-structs \ + $(NULL) if WITH_REMOTE check-protocol: $(PROTOCOL_STRUCTS) $(PROTOCOL_STRUCTS:structs=struct) @@ -338,6 +340,9 @@ $(srcdir)/remote_protocol-struct $(srcdir)/qemu_protocol-struct: \ $(srcdir)/virnetprotocol-struct $(srcdir)/virkeepaliveprotocol-struct: \ $(srcdir)/%-struct: libvirt_net_rpc_la-%.lo $(PDWTAGS) +# lock_protocol is built without libtool +$(srcdir)/lock_protocol-struct: $(srcdir)/%-struct: virtlockd-%.o + $(PDWTAGS) else !WITH_REMOTE # The $(PROTOCOL_STRUCTS) files must live in git, because they cannot be # re-generated when configured --without-remote. diff --git c/src/lock_protocol-structs i/src/lock_protocol-structs new file mode 100644 index 0000000..444bdb1 --- /dev/null +++ i/src/lock_protocol-structs @@ -0,0 +1,51 @@ +/* -*- c -*- */ +struct virLockSpaceProtocolOwner { + virLockSpaceProtocolUUID uuid; + virLockSpaceProtocolNonNullString name; + u_int id; + u_int pid; +}; +struct virLockSpaceProtocolRegisterArgs { + virLockSpaceProtocolOwner owner; + u_int flags; +}; +struct virLockSpaceProtocolRestrictArgs { + u_int flags; +}; +struct virLockSpaceProtocolNewArgs { + virLockSpaceProtocolNonNullString path; + u_int flags; +}; +struct virLockSpaceProtocolCreateResourceArgs { + virLockSpaceProtocolNonNullString path; + virLockSpaceProtocolNonNullString name; + u_int flags; +}; +struct virLockSpaceProtocolDeleteResourceArgs { + virLockSpaceProtocolNonNullString path; + virLockSpaceProtocolNonNullString name; + u_int flags; +}; +enum virLockSpaceProtocolAcquireResourceFlags { + VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = 1, + VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = 2, +}; +struct virLockSpaceProtocolAcquireResourceArgs { + virLockSpaceProtocolNonNullString path; + virLockSpaceProtocolNonNullString name; + u_int flags; +}; +struct virLockSpaceProtocolReleaseResourceArgs { + virLockSpaceProtocolNonNullString path; + virLockSpaceProtocolNonNullString name; + u_int flags; +}; +enum virLockSpaceProtocolProcedure { + VIR_LOCK_SPACE_PROTOCOL_PROC_REGISTER = 1, + VIR_LOCK_SPACE_PROTOCOL_PROC_RESTRICT = 2, + VIR_LOCK_SPACE_PROTOCOL_PROC_NEW = 3, + VIR_LOCK_SPACE_PROTOCOL_PROC_CREATE_RESOURCE = 4, + VIR_LOCK_SPACE_PROTOCOL_PROC_DELETE_RESOURCE = 5, + VIR_LOCK_SPACE_PROTOCOL_PROC_ACQUIRE_RESOURCE = 6, + VIR_LOCK_SPACE_PROTOCOL_PROC_RELEASE_RESOURCE = 7, +}; [oh yuck - on re-reading that, we may have issues if someone configures where WITH_REMOTE and WITH_LIBVIRTD are not both empty or both set - I may have to do followup patches for those scenarios].
+++ b/cfg.mk @@ -813,3 +813,6 @@ exclude_file_name_regexp--sc_unmarked_diagnostics = \ ^(docs/apibuild.py|tests/virt-aa-helper-test)$$
exclude_file_name_regexp--sc_size_of_brackets = cfg.mk + +exclude_file_name_regexp--sc_correct_id_types = \ + (^src/locking/lock_protocol.x$$)
Not sorted.
+++ b/src/locking/lock_protocol.x +struct virLockSpaceProtocolOwner { + virLockSpaceProtocolUUID uuid; + virLockSpaceProtocolNonNullString name; + unsigned int id; + unsigned int pid;
Are we sure that this will always be wide enough? That is, does the virtlockd binary make sense on mingw, where pid_t is 64 bits, or are we reasonably sure that we are safe with restricting the RPC call to 32 bits because it will only ever be used on UNIX-y systems?
+enum virLockSpaceProtocolProcedure { + /* Each function must have a two-word comment. The first word is + * whether remote_generator.pl handles daemon, the second whether + * it handles src/remote. Additional flags can be specified after a + * pipe. + */ + VIR_LOCK_SPACE_PROTOCOL_PROC_REGISTER = 1, /* skipgen skipgen */ + VIR_LOCK_SPACE_PROTOCOL_PROC_RESTRICT = 2, /* skipgen skipgen */ + VIR_LOCK_SPACE_PROTOCOL_PROC_NEW = 3, /* skipgen skipgen */ + VIR_LOCK_SPACE_PROTOCOL_PROC_CREATE_RESOURCE = 4, /* skipgen skipgen */ + VIR_LOCK_SPACE_PROTOCOL_PROC_DELETE_RESOURCE = 5, /* skipgen skipgen */ + + VIR_LOCK_SPACE_PROTOCOL_PROC_ACQUIRE_RESOURCE = 6, /* skipgen skipgen */ + VIR_LOCK_SPACE_PROTOCOL_PROC_RELEASE_RESOURCE = 7 /* skipgen skipgen */
I guess you didn't bother hooking this up to remote_generator.pl :) For only 7 functions, that's probably okay. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org