Apologies to those that get this twice, resending from an account thats signed up to the
matahari list.
On May 24, 2010, at 4:45 PM, Amit Shah wrote:
On (Fri) May 21 2010 [12:38:12], Perry Myers wrote:
>> For virtio we will have a char device in the guest which maps to a
>> UNIX domain socket on the host. This is our channel. There is no TCP,
>> no network, etc. It is more like a named pipe than anything else. We
>> want to provide a mechanism for requesting information from the guest
>> and getting a response. We don't want to add any new code to the
>> application (host) side.
>>
>> Back to your definition of RPC, Darryl. I think you have the right
>> idea, I just wouldn't call it RPC. If I understand all the
>> requirements, we should be able to simply send our requests/responses
>> in XML format between the two endpoints. We can publish a DTD and
>> application developers can adhere to that. Personally, I think a
>> library would be useful, but we can worry about that later.
>>
>> Am I making sense or is this complete rubbish?
>
> That all makes sense to me. And I agree about providing a library on the
> host side of the pipe as an enhancement, but we should focus first on the
> guest side of things.
>
> David/Ian/Alan/Andrew, you guys all think this sounds reasonable as well?
>
> Amit/Barak, what do you guys think given your experience with the existing
> usage of vmchannel (our understanding is that presently pack/unpack of
> python structs are just sent over the current vmchannel pipe)
I agree with everything written above: something like a libvirtioserial
on the guest side makes sense.
On the host side we'd need a similar library that can be linked to
within qemu as well for in-qemu apps.
In addition to the header Perry mentioned (on irc) that contains:
endianness info
size of packet
I was thinking of having some more fields: feature bits negotiated
between the host and guest libraries (header sizes may vary, for
example), once all features are negotiated.
I think we need to include this in the header of every message sent between the guest and
host.
I'd imagine that the capabilities would be part of the body of messages exchanged
during the negotiation stage.
After that they're not going to change, so why resend every time?
Apps layered on top of this library could themselves negotiate for
features, and that could be an app-specific header, or we could reserve
some space in the library's initial handshake header as well:
guest_features = F_CLIPBOARD | F_CLIPBOARD2;
host_features = virtioserial_connect("/dev/virtio-ports/something",
guest_features);
if (host_features < 0) {
...
} else {
features = guest_features & host_features;
}
if (features & F_CLIPBOARD2) {
...
}
something like that.
Anyway, these are just some quick initial thoughts; let me know if
there's any more discussion surrounding the use-cases and we can decide
on the design.
Also, Perry mentions an XML payload, but the payload could really be
anything; example a clipboard copy-paste app will just have free-flowing
data (unless a key-value protocol is being proposed as part of the
libvirtioserial library).
Agreed, the type in the header should be void* rather than char* and we should include a
"type" field in the header.
-- Andrew