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 :)
Rusty.
--
To unsubscribe from this list: send the line
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
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 [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
having
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
--
To unsubscribe from this list: send
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 udev for
userspace to make use of.
Let me explain how we
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
Gerd Hoffmann wrote:
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.
Gerd Hoffmann wrote:
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.
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
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.
There certainly is from me. The userspace
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.
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 devices.
Hot add/remove is
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 /dev/vmch*
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 /dev/vmch*
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 don't think that's not too bad, for example, with fast-user-switching
between multiple X servers and/or text consoles, there's already support
code that deals with chown'ing things like /dev/snd/* devices to match
the active console session. Doing the same with the
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,
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 user has the active X
session that's controlling the
46 matches
Mail list logo
