[libvirt] non-standard types in remote XDR definitions
Hello, I have been experimenting with the remote protocol defined in the `src/remote/remote_protocol.x` (https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/remote/remote_prot...), and noticed that there a number of types used that are not defined in the XDR RFC, specifically: unsigned char, char, unsigned short, short (I might have missed one or two). I'm wondering if these are missing typedefs, or whether they are custom extensions to the RFC. Does anyone have more information on this? If the latter case is the fact, are these values padded to 4 bytes per the spec? Thanks, Matt
On Wed, Jan 25, 2017 at 10:55:37AM -0500, Matt Broadstone wrote:
Hello,
I have been experimenting with the remote protocol defined in the `src/remote/remote_protocol.x` (https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/remote/remote_prot...), and noticed that there a number of types used that are not defined in the XDR RFC, specifically: unsigned char, char, unsigned short, short (I might have missed one or two). I'm wondering if these are missing typedefs, or whether they are custom extensions to the RFC. Does anyone have more information on this? If the latter case is the fact, are these values padded to 4 bytes per the spec?
The libvirt RPC protocol is an internal impl detail, not for 3rd party use. So our only goal is to be compatible with rpcgen binaries that are used during builds on supported platforms. As such what's in the RFC is not particularly relevant. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On Wed, Jan 25, 2017 at 10:59 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Wed, Jan 25, 2017 at 10:55:37AM -0500, Matt Broadstone wrote:
Hello,
I have been experimenting with the remote protocol defined in the `src/remote/remote_protocol.x` (https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/remote/remote_prot...), and noticed that there a number of types used that are not defined in the XDR RFC, specifically: unsigned char, char, unsigned short, short (I might have missed one or two). I'm wondering if these are missing typedefs, or whether they are custom extensions to the RFC. Does anyone have more information on this? If the latter case is the fact, are these values padded to 4 bytes per the spec?
The libvirt RPC protocol is an internal impl detail, not for 3rd party use. So our only goal is to be compatible with rpcgen binaries that are used during builds on supported platforms. As such what's in the RFC is not particularly relevant.
It does appear that these types are indeed supported by rpcgen (though in the cases where char's are used, your definitions would benefit from a conversion to `opaque`, as to not incur the padding overhead). Thank you for the clarification. Matt
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On Wed, Jan 25, 2017 at 11:12:33AM -0500, Matt Broadstone wrote:
On Wed, Jan 25, 2017 at 10:59 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Wed, Jan 25, 2017 at 10:55:37AM -0500, Matt Broadstone wrote:
Hello,
I have been experimenting with the remote protocol defined in the `src/remote/remote_protocol.x` (https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/remote/remote_prot...), and noticed that there a number of types used that are not defined in the XDR RFC, specifically: unsigned char, char, unsigned short, short (I might have missed one or two). I'm wondering if these are missing typedefs, or whether they are custom extensions to the RFC. Does anyone have more information on this? If the latter case is the fact, are these values padded to 4 bytes per the spec?
The libvirt RPC protocol is an internal impl detail, not for 3rd party use. So our only goal is to be compatible with rpcgen binaries that are used during builds on supported platforms. As such what's in the RFC is not particularly relevant.
It does appear that these types are indeed supported by rpcgen (though in the cases where char's are used, your definitions would benefit from a conversion to `opaque`, as to not incur the padding overhead). Thank you for the clarification.
Converting 'char' to 'opaque' would break wire ABI back-compatibility so is not an option. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
participants (2)
-
Daniel P. Berrange -
Matt Broadstone