On Wed, Jul 29, 2009 at 01:14:18PM +0530, Amit Shah wrote:
quoted text
> On (Tue) Jul 28 2009 [08:42:32], Anthony Liguori wrote:
> > Amit Shah wrote:
> >> Right; use virtio just as the transport and all the interesting
> >> activity happens in userspaces. That was the basis with which I started.
> >> I can imagine dbus doing the copy/paste, lock screen, etc. actions.
> >>
> >> However for libguestfs, dbus isn't an option and they already have some
> >> predefined agents for each port. So libguestfs is an example for a
> >> multi-port usecase for virtio-serial.
> >>   
> >
> > Or don't use dbus and use something that libguestfs is able to embed.   
> > The fact that libguestfs doesn't want dbus in the guest is not an  
> > argument for using a higher level kernel interface especially one that  
> > doesn't meet the requirements of the interface.
> 
> But why do we want to limit the device to only one port? It's not too
> complex supporting additional ones.
> 
> As I see it qemu and the kernel should provide the basic abstraction for
> the userspace to go do its job. Why create unnecessary barriers?
> 
I agree. If userspace wants it may use only one channel and demultiplex
messages by itself, but we shouldn't force it to. Also one of the
requirements for virtio-serial is to have connect disconnect
notifications. It is not possible with demultiplexing in the userspace.

--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html