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 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 "u
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
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 t
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
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 som
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
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 sysf
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 protoc
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,
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
h
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
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
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 mor
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 functional
> 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: s
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 sophis
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 mechanis
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 duplicat
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 in
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 t
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 de
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.
W
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.
W
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 (a)
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 virti
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 c
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 n
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 devi
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
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 interfac
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
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 (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
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 enum
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
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 supporte
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 g
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
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*
de
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 ima
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.
>>
>> Howe
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 just
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
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*
de
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 (o
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
pr
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
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 physic
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 t
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 /d
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)
> > - c
52 matches
Mail list logo
