On Tue, May 25, 2010 at 9:33 PM, Ryan O'Hara <rohara(a)redhat.com> wrote:
On Mon, May 24, 2010 at 08:15:23PM +0530, 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.
>
> 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).
My 2c on this discussion:
We're talking about a way to communicate with Matahari running on the
guest, correct? Or are we talking about defining a generic format for
talking over virtio?
The former with the idea that it will evolve into the latter.
Not that it would be the only way to talk over virtio, but like say
ISO8601*, it would be there as an off-the-shelf spec** that would
handle most developer use cases.
* A real example from Pacemaker. I could have reinvented the wheel,
but there was already a standard way of expressing dates, times and
intervals
** And later an implementation
It seems odd to define anything more than a format for messages going
between the host application and Matahari (on the guest) over
virtio. This virtio channel can be considered to be nothing more than
a pipe. It can be used but anyone for any reason. I see no need to
define a general format for virtio communication.
This is where I think a library (installed on the host) is
appropriate.
No doubt there will eventually be a library.
BUT
a) its not a requirement - any program in any language adhering to
the format can be on the other side of the pipe
b) we don't have to be the ones that write it, or at least "not yet"
Its purpose would be for communicating with with
Matahari, nothing more. It could be used, of course, by any
application that wants to talk to the Matahari agent. That said, I
think a Matahari "client" library is appropriate. It seems odd to
define the message format in the virtio library.
Ryan
_______________________________________________
Matahari mailing list
Matahari(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/matahari