From: Anthony Liguori <anthony@codemonkey.ws>
To: Amit Shah <amit.shah@redhat.com>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
Rusty Russell <rusty@rustcorp.com.au>,
"Richard W.M. Jones" <rjones@redhat.com>,
virtualization@lists.linux-foundation.org
Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Date: Mon, 10 Aug 2009 09:27:01 -0500 [thread overview]
Message-ID: <4A802E35.1040308@codemonkey.ws> (raw)
In-Reply-To: <20090810065508.GA4499@amit-x200.redhat.com>
Amit Shah wrote:
> Let me explain how we came to this numbering: we first had support for
> 'naming' ports and the names were obtained by userspace programs by an
> ioctl. Rusty suggested to use some numbering scheme where some ports
> could exist at predefined locations so that we wouldn't need the naming
> and the ioctls around it.
>
Fortunately, if you implement the naming scheme in userspace you get the
best of both worlds ;-)
>>> Hm, so there can be one daemon on the guest handling all clipboard
>>> events. There's some work done already by the fast-user-switch support
>>> and that can be extended to daemons that talk over virtio-serial.
>>>
>>>
>> You could have one daemon that manages all vmchannel sessions. It can
>> then expose channels to apps via whatever mechanism is best. It could
>> use unix domain sockets, sys v ipc, whatever floats your boat.
>>
>> And, you can build this daemon today using the existing vmchannel over
>> TCP/IP. You could also make it support serial devices. We could also
>> introduce a custom usb device and use libusb. libusb is portable to
>> Windows and Linux.
>>
>
> There are some other problems with usb too: It's not transparent to
> users. Any hotplug event could alert users and that's not desired.
I don't think this is true in practice. Our goal is not to circumvent
an OS's policy decisions either.
> It's
> a system-only thing and should also remain that way.
>
I don't buy this argument at all. If you exposed a new usb device that
no OS had a kernel driver, and you had a daemon running that watched for
insertions of that device, what OS would that not work transparently on?
I think my fundamental argument boils down to two points. 1) we should
not require new guest drivers unless we absolutely have to 2) we should
always do things in userspace unless we absolutely have to do things in
the kernel.
Adding new kernel drivers breaks support for enterprise Linux distros.
Adding a userspace daemon does not. Windows device drivers require
signing which is very difficult to do. There's a huge practical
advantage in not requiring guest drivers.
Regards,
Anthony Liguori
> Amit
>
next prev parent reply other threads:[~2009-08-10 14:27 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-27 18:04 [Qemu-devel] virtio-serial: An interface for host-guest communication Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 1/1] virtio_serial: A char device for simple guest <-> host communication Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 1/3] virtio-serial: virtio device for simple host <-> guest communication Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 2/3] vnc: add a is_vnc_active() helper Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 3/3] virtio-serial: vnc: support for sending / receiving guest clipboard Amit Shah
2009-08-05 0:03 ` [Qemu-devel] Re: [PATCH 1/1] virtio_serial: A char device for simple guest <-> host communication Rusty Russell
2009-08-05 5:12 ` Amit Shah
2009-08-05 9:58 ` Amit Shah
2009-07-27 20:22 ` [Qemu-devel] Re: virtio-serial: An interface for host-guest communication Anthony Liguori
2009-07-27 20:32 ` Daniel P. Berrange
2009-07-27 20:37 ` Anthony Liguori
2009-07-27 20:46 ` Jamie Lokier
2009-07-27 23:44 ` Anthony Liguori
2009-07-28 10:36 ` Amit Shah
[not found] ` <4A6F0048.1000103@codemonkey.ws>
2009-07-29 7:44 ` Amit Shah
2009-07-29 7:48 ` Gleb Natapov
2009-08-05 18:00 ` Jamie Lokier
[not found] ` <20090728140029.GA16067@amd.home.annexia.org>
2009-07-28 14:48 ` Anthony Liguori
2009-07-28 14:55 ` Richard W.M. Jones
2009-07-28 15:00 ` Anthony Liguori
2009-08-03 19:57 ` Anthony Liguori
2009-08-05 17:57 ` Jamie Lokier
2009-08-05 18:00 ` Anthony Liguori
2009-08-06 10:38 ` Amit Shah
2009-08-06 13:29 ` Anthony Liguori
2009-08-06 13:41 ` Amit Shah
2009-08-06 13:58 ` Anthony Liguori
2009-08-06 14:04 ` Amit Shah
2009-08-06 17:37 ` Jamie Lokier
2009-08-07 6:38 ` Amit Shah
2009-08-07 14:14 ` Anthony Liguori
2009-08-10 6:55 ` Amit Shah
2009-08-10 9:47 ` Gerd Hoffmann
2009-08-10 13:02 ` Anthony Liguori
2009-08-10 14:02 ` Gerd Hoffmann
2009-08-10 14:20 ` Anthony Liguori
2009-08-10 15:34 ` Gerd Hoffmann
2009-08-10 16:59 ` Anthony Liguori
2009-08-10 17:27 ` Anthony Liguori
2009-08-12 18:27 ` Paul Brook
2009-08-14 8:15 ` Amit Shah
2009-08-14 13:29 ` Anthony Liguori
2009-08-14 13:41 ` Amit Shah
2009-08-20 13:42 ` Amit Shah
2009-08-20 14:25 ` Daniel P. Berrange
2009-08-20 14:38 ` Amit Shah
2009-08-20 14:42 ` Amit Shah
2009-08-14 13:49 ` Gerd Hoffmann
2009-08-14 16:25 ` Anthony Liguori
2009-08-20 7:31 ` Rusty Russell
2009-08-20 7:44 ` Gerd Hoffmann
2009-08-20 7:55 ` Amit Shah
2009-08-20 17:10 ` Jamie Lokier
2009-08-25 12:43 ` Rusty Russell
2009-08-25 13:00 ` Gerd Hoffmann
2009-08-10 14:20 ` Anthony Liguori
2009-08-10 23:09 ` Rusty Russell
2009-08-11 0:16 ` Anthony Liguori
2009-08-10 14:27 ` Anthony Liguori [this message]
2009-08-10 15:57 ` Gerd Hoffmann
2009-08-06 10:35 ` Amit Shah
2009-08-05 18:32 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A802E35.1040308@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=amit.shah@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).