Re: [libvirt] [PATCH 18/23] Define a wire protocol for talking to the virtlockd daemon

On 08/09/2012 09:20 AM, Daniel P. Berrange wrote: 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]. Not sorted. 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? I guess you didn't bother hooking this up to remote_generator.pl :) For only 7 functions, that's probably okay. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org