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 s
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.
___
Vi
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
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
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
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
___
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 wh
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
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 i
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
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 ext
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 th
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 ident
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 ident
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 b
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
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 expl
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 n
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 the way major-minor numbering works on the Linux
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
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/r
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
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
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
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
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
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
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
55 matches
Mail list logo
