On 08/25/09 14:43, Rusty Russell wrote:
On Thu, 20 Aug 2009 05:14:29 pm Gerd Hoffmann wrote:
I think strings are better as numbers for identifying protocols as you
can work without a central registry for the numbers then.
Yep, all you need is a central registry for names :)
There are schemes
On Sat, 15 Aug 2009 01:55:32 am Anthony Liguori wrote:
Gerd Hoffmann wrote:
Also I still think passing a 'protocol' string for each port is a good
idea, so you can stick that into a sysfs file for guests use.
Or drops ports altogether and just use protocol strings...
Both is silly, yes.
On 08/20/09 09:31, Rusty Russell wrote:
On Sat, 15 Aug 2009 01:55:32 am Anthony Liguori wrote:
Gerd Hoffmann wrote:
Also I still think passing a 'protocol' string for each port is a good
idea, so you can stick that into a sysfs file for guests use.
Or drops ports altogether and just use
On (Thu) Aug 20 2009 [09:44:29], Gerd Hoffmann wrote:
On 08/20/09 09:31, Rusty Russell wrote:
On Sat, 15 Aug 2009 01:55:32 am Anthony Liguori wrote:
Gerd Hoffmann wrote:
Also I still think passing a 'protocol' string for each port is a good
idea, so you can stick that into a sysfs file for
On (Fri) Aug 14 2009 [08:29:28], Anthony Liguori wrote:
Amit Shah wrote:
On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote:
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with
virtio-console. If the two are
On Thu, Aug 20, 2009 at 07:12:41PM +0530, Amit Shah wrote:
I've now seen some more code here and to me it looks like virtioconsole
is not used on any of the guests that qemu supports. The virtio_console
kernel module only works with lguest and s390 currently. There is one
feature and some
On (Thu) Aug 20 2009 [15:25:09], Daniel P. Berrange wrote:
On Thu, Aug 20, 2009 at 07:12:41PM +0530, Amit Shah wrote:
I've now seen some more code here and to me it looks like virtioconsole
is not used on any of the guests that qemu supports. The virtio_console
kernel module only works
On (Thu) Aug 20 2009 [20:08:02], Amit Shah wrote:
On (Thu) Aug 20 2009 [15:25:09], Daniel P. Berrange wrote:
On Thu, Aug 20, 2009 at 07:12:41PM +0530, Amit Shah wrote:
I've now seen some more code here and to me it looks like virtioconsole
is not used on any of the guests that qemu
Amit Shah wrote:
I think strings are better as numbers for identifying protocols as you
can work without a central registry for the numbers then.
I like the way assigned numbers work: it's simpler to code, needs a
bitmap for all the ports that fits in nicely in the config space and
udev
On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote:
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with virtio-console.
If the two are converged, I'm happy to merge it. I'm not opposed to
having more functionality.
Amit Shah wrote:
On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote:
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with virtio-console.
If the two are converged, I'm happy to merge it. I'm not opposed to
On (Fri) Aug 14 2009 [08:29:28], Anthony Liguori wrote:
Amit Shah wrote:
On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote:
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with
virtio-console. If the two are
On 08/14/09 10:15, Amit Shah wrote:
The guest code sort-of ends up looking like this after merging
virtio_console into virtio_serial.
I think it should better go the other way around: add multichannel
support to virtio-concole, probably guarded by a feature flag so old
host+new guest and new
Gerd Hoffmann wrote:
On 08/14/09 10:15, Amit Shah wrote:
The guest code sort-of ends up looking like this after merging
virtio_console into virtio_serial.
I think it should better go the other way around: add multichannel
support to virtio-concole, probably guarded by a feature flag so old
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with virtio-console.
If the two are converged, I'm happy to merge it. I'm not opposed to
having more functionality.
I strongly agree.
Paul
On (Fri) Aug 07 2009 [09:14:43], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
Apart from dbus, hard-coded meanings of small N in /dev/vmchN are
asking for trouble. It is bound to break when widely deployed and
It's no different from
Gerd Hoffmann wrote:
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. It's
a system-only thing and should also remain that way.
I think virtio-serial is the better way to handle vmchannel. Unlike
usb
On 08/10/09 15:02, Anthony Liguori wrote:
I think you're missing my fundamental point. Don't use the kernel as the
guest interface.
Introduce a userspace daemon that exposes a domain socket. Then we can
have a proper protocol that uses reverse fqdns for identification.
We need nothing but
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
On 08/10/09 16:20, Anthony Liguori wrote:
Gerd Hoffmann wrote:
Do we really want design a daemon and a protocol for such a simple thing?
Yes, because we also need (c) the ability to write cross platform
software that targets vmchannel.
So having a library interface is going to be extremely
On 08/10/09 16:27, Anthony Liguori wrote:
I think my fundamental argument boils down to two points. 1) we should
not require new guest drivers unless we absolutely have to
Allow guest drivers is fine though I guess?
2) we should
always do things in userspace unless we absolutely have to do
Gerd Hoffmann wrote:
Ok, lets rip out the in-kernel ioapic code then. It can (and has
been) done in userspace.
The justification is performance although that's not really true anymore
post TPR optimization.
But FWIW, I opposed both the in-kernel apic and the in-kernel pit when
they were
Anthony Liguori wrote:
There is nothing sane about vmchannel. It's just an attempt to bypass
QEMU which is going to introduce all sorts of complexities wrt
migration, guest compatibility, etc.
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it
On Mon, 10 Aug 2009 07:17:54 pm Gerd Hoffmann wrote:
On 08/10/09 08:55, Amit Shah wrote:
Bad example. Quite a lot of modern devices drivers are using dynamic
major/minor numbers because they have proven to be such a pain in the
butt. That's why we have more sophisticated mechanisms like
Rusty Russell wrote:
On Mon, 10 Aug 2009 07:17:54 pm Gerd Hoffmann wrote:
On 08/10/09 08:55, Amit Shah wrote:
Bad example. Quite a lot of modern devices drivers are using dynamic
major/minor numbers because they have proven to be such a pain in the
butt. That's why we have more
On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from
On (Wed) Aug 05 2009 [18:57:13], Jamie Lokier wrote:
Anthony Liguori wrote:
Richard W.M. Jones wrote:
Have you considered using a usb serial device? Something attractive
about it is that a productid/vendorid can be specified which means that
you can use that as a method of enumerating
On (Wed) Aug 05 2009 [13:00:57], Anthony Liguori wrote:
Jamie Lokier wrote:
Anthony Liguori wrote:
Richard W.M. Jones wrote:
Have you considered using a usb serial device? Something attractive
about it is that a productid/vendorid can be specified which means
that you can use that as
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interface is not reasonable
for guest applications to use.
Regards,
Anthony Liguori
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interface is not reasonable
for
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we
Anthony Liguori wrote:
Richard W.M. Jones wrote:
Have you considered using a usb serial device? Something attractive
about it is that a productid/vendorid can be specified which means that
you can use that as a method of enumerating devices.
Hot add/remove is supported automagically.
Gleb Natapov wrote:
On Wed, Jul 29, 2009 at 01:14:18PM +0530, Amit Shah wrote:
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
On Mon, Aug 03, 2009 at 02:57:01PM -0500, Anthony Liguori wrote:
Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
... or a more flexible API. I don't like having fixed
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
On Wed, Jul 29, 2009 at 01:14:18PM +0530, Amit Shah wrote:
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
On (Mon) Jul 27 2009 [18:44:28], Anthony Liguori wrote:
Jamie Lokier wrote:
With multiple X servers, there can be more than one currently logged in user.
Same with multiple text consoles - that's more familiar.
Which one owns /dev/vmch3?
For a VMM, copy/paste should work with whatever
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
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
... or a more flexible API. I don't like having fixed /dev/vmch*
devices either.
A long time ago (on
Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
... or a more flexible API. I don't like having fixed
On Tue, Jul 28, 2009 at 09:48:00AM -0500, Anthony Liguori wrote:
Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
Richard W.M. Jones wrote:
On Tue, Jul 28, 2009 at 09:48:00AM -0500, Anthony Liguori wrote:
Dave Miller nacked that approach with a sledgehammer instead preferring
that we just use standard TCP/IP which is what led to the current
implementation using slirp.
I'm aware of that - I
On Mon, Jul 27, 2009 at 03:22:54PM -0500, Anthony Liguori wrote:
Amit Shah wrote:
Hello all,
This are the latest version of the patches.
Lots of things have changed since the last submission. A few of
which I remember:
- VNC copy / paste works* (* conditions apply)
- client vnc copies
Daniel P. Berrange wrote:
I expect the first problem you'll run into is that copy/paste daemon has
to run as an unprivileged user but /dev/vmch3 is going to be owned by
root. You could set udev rules for /dev/vmch3 but that's pretty
terrible IMHO.
I don't think that's not too bad,
46 matches
Mail list logo