----- Original Message ----- > From: "Marc-André Lureau" <marcandre.lureau@xxxxxxxxx> > To: "Alon Bar-Lev" <alonbl@xxxxxxxxxx> > Cc: "spice-devel" <spice-devel@xxxxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, November 19, 2013 2:50:17 PM > Subject: Re: Implementing channel between module at spice client and guest OS > > Hi > Hi, Thank you for your response. Just a few clarification bellow. > On Mon, Nov 18, 2013 at 7:22 PM, Alon Bar-Lev <alonbl@xxxxxxxxxx> wrote: > > Hello, > > > > I am trying to figure out how to implement a channel between guest OS > > process and component at client machine. Reading the documentation I found > > and the vd_agent code which is somewhat similar but I could not find > > complete solution. > > > > Here is what I imagined.... > > > > I define a new serial interface on qemu: > > > > -device virtio-serial-pci > > -device virtserialport,chardev=myappl,name=my.application.0 > > -chardev spicevmc,id=myappl,name=myappl > > > > This will enable a process within guest os to access > > /dev/virtio-ports/my.application.0 > > > If you use a spicevmc name, you'll have to modify Spice server > (spice_server_char_device_add_interface), and implement the channel > handling in client. This can be tedious and doesn't allow "private" > extensions. > > But recently, we added the spice "port", which is just like spicevmc, > except that you can have "private channels" without modifiying server > etc. > > It hasn't been widely used (even less when connected to a virtio > port), but you can try using it: > > -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? > > 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? And I use spice_port_write_async/spice_port_event to manage this channel, right? > > > 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? I mean if such support will be submitted will it be rejected? > > > 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. > > > > Another nice option I thought is to allow forking process at client side > > with usock as stdin/stdout that redirected into specific spicevmc device, > > this will ease the work of implementing such solutions, as the author of > > the forked process may not have any spice knowledge at all, while be able > > to participate within the solution. > > That's a possibility, patches welcome. Evaluating the options... :) Thanks, Alon Bar-Lev. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel