[Spice-devel] Implementing channel between module at spice client and guest OS

Alon Bar-Lev alonbl at redhat.com
Tue Nov 19 11:02:21 PST 2013


Thank you for the details!
Back to drawing board.

----- Original Message -----
> From: "Marc-André Lureau" <mlureau at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Marc-André Lureau" <marcandre.lureau at gmail.com>, "spice-devel" <spice-devel at lists.freedesktop.org>
> Sent: Tuesday, November 19, 2013 3:22:47 PM
> Subject: Re: [Spice-devel] Implementing channel between module at spice client and guest OS
> 
> Hi
> 
> ----- Original Message -----
> > > -chardev spiceport,id=spiceportfoobar,name=com.foobar -device
> > > virtserialport,bus=virtio-serial0.0,nr=2,chardev=spiceportfoobar,id=channel1,name=com.foobar
> > 
> > Just to make sure, this will create serial device at
> > /dev/virtio-ports/com.foobar, right?
> 
> yes
> 
> > > > At client side I would like to implement a component that interact with
> > > > this myappl port, I could not find a way to load shared library or
> > > > similar
> > > > dynamic module into client in spicy usage.
> > > >
> > > 
> > > At client side, you can follow spicy.c example. In channel_new(), you
> > > want to connect to the port channel signals. When
> > > "notify::port-opened", you can decide to handle that channel  based on
> > > its "port-name".
> > 
> > Which is spiceportfoobar in above example, right?
> 
> No, this is qemu device name. The port name is "com.foobar"
> (spiceport,..name=)
> 
> > And I use spice_port_write_async/spice_port_event to manage this channel,
> > right?
> 
> Yes, check spicy.c example code.
> 
> > > 
> > > > If dynamic loading of modules is possible, is there any example of how
> > > > to
> > > > do so?
> > > >
> > > > If dynamic loading of modules is impossible, is there a plan to allow
> > > > it?
> > > 
> > > There is currently no registry of channel or port handlers to be
> > > loaded dynamically. There is currently no plan to add it, but that
> > > could be added later.
> > 
> > Is there a reason against of having something dynamic?
> 
> No, it's just not needed so far.
> 
> > I mean if such support will be submitted will it be rejected?
> 
> No, this use case is perfectly valid. Just make sure to propose a generic
> solution.
> 
> > 
> > > 
> > > > Assuming there is the option to load a module.
> > > >
> > > > I could not find in vdi spec[1] description of the vdi_port interface
> > > > and
> > > > what should I do in order to communicate with the guest.
> > > >
> > > > Provided this is possible somehow, as it is working for vd_agent... and
> > > > provided external modules can be loaded.
> > > >
> > > > I can guess that each 'name' in the above example myapp can be
> > > > connected
> > > > by
> > > > different implementation, is that right?
> > > >
> > > > Assuming we have channel between module running on client machine and
> > > > the
> > > > agent running on guest machine using virtual serial, is there support
> > > > for
> > > > transferring RS232 controls? Such as DTR/DSR to detect if the device is
> > > > opened at guest side and if device is opened at client side? And detect
> > > > disconnection?
> > > 
> > > 
> > > You can also redirect a serial device from qemu:
> > > 
> > > -chardev spiceport,id=spiceportfoobar,name=org.spice.spicy -serial
> > > chardev:spiceportfoobar
> > > 
> > > (with kernel argument "console=tty0 console=ttyS0,115200n8")
> > 
> > Here I lost you... I do not need the 'console'... I need a channel of
> > following:
> > 
> > module -> client ----spice-protocol----> qemu --> guest --> application
> > 
> > so that:
> > 
> > module <---------------------stream-----------------------> application
> > 
> > My questions now are:
> > 1. how application know if there is module on the other side?
> > 2. how module knows if there is application on the other side?
> > 
> > Had this standard RS-232 I could use DTR/DSR... but maybe it is a better
> > way... or none.
> 
> I think you should be able to use the port event for that. But you'll have to
> do some reasearch, this is new territory :)
> 


More information about the Spice-devel mailing list