On Fri, May 21, 2010 at 6:38 PM, Perry Myers <pmyers(a)redhat.com> 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?
Yep. No complaints here.
The only thing to keep in mind is what sort of header[1] you package
the XML up in.
Doing that in a language neutral way might be tricky, so perhaps the
best fallback is a C struct (similar to corosync) of the form:
struct mh_message_s {
int payload_len;
char checksum[SOMESIZE];
void *payload;
}
and eventually we can provide a simple C library function that can be
called from python/java/whatever.
Oh, and I'd encourage Relax-NG instead of DTD.
But thats an implementation detail.
-- Andrew
[1] so the other side knows how much data to read, otherwise you end
up having to read one char at a time
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)
Thanks,
Perry
_______________________________________________
Matahari mailing list
Matahari(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/matahari