Hi Dave,
> >> Instead, what I remember doing was deferring to the feedback these
> >> folks received, stating that ideas that the virtio people had
> >> mentioned should be considered instead.
> >>
> >> http://marc.info/?l=linux-netdev=135301515818462=2
> >
> > I believe Andy replied to
Hi Dave,
Instead, what I remember doing was deferring to the feedback these
folks received, stating that ideas that the virtio people had
mentioned should be considered instead.
http://marc.info/?l=linux-netdevm=135301515818462w=2
I believe Andy replied to Anthony's AF_VMCHANNEL
> > > Our position is that VSOCK feature set is more complete and that
> > > it
> > > should be possible to use transports other than VMCI for VSOCK
> > > traffic, should interested parties implement them,
> >
> > Implementing other transports requires restructing vsock (and vmci)
> > first as
Our position is that VSOCK feature set is more complete and that
it
should be possible to use transports other than VMCI for VSOCK
traffic, should interested parties implement them,
Implementing other transports requires restructing vsock (and vmci)
first as the current vsock
> > Our position is that VSOCK feature set is more complete and that it
> > should be possible to use transports other than VMCI for VSOCK
> > traffic, should interested parties implement them,
>
> Implementing other transports requires restructing vsock (and vmci)
> first as the current vsock
On 01/09/13 03:22, Dmitry Torokhov wrote:
> On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote:
>> I'd much rather see a hypervisor neutral solution than a hypervisor
>> specific one which this certainly is.
>
> Objectively speaking neither solution is hypervisor neutral as there are
>
On 01/09/13 03:22, Dmitry Torokhov wrote:
On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote:
I'd much rather see a hypervisor neutral solution than a hypervisor
specific one which this certainly is.
Objectively speaking neither solution is hypervisor neutral as there are
Our position is that VSOCK feature set is more complete and that it
should be possible to use transports other than VMCI for VSOCK
traffic, should interested parties implement them,
Implementing other transports requires restructing vsock (and vmci)
first as the current vsock code is not
On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote:
> From: Dmitry Torokhov
> Date: Tue, 08 Jan 2013 17:41:44 -0800
>
> > On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote:
> >> From: Greg KH
> >> Date: Tue, 8 Jan 2013 16:21:10 -0800
> >>
> >> > On Tue, Jan 08, 2013 at
From: Dmitry Torokhov
Date: Tue, 08 Jan 2013 17:41:44 -0800
> On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote:
>> From: Greg KH
>> Date: Tue, 8 Jan 2013 16:21:10 -0800
>>
>> > On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote:
>> >> * * *
>> >>
>> >> This series of
On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote:
> From: Greg KH
> Date: Tue, 8 Jan 2013 16:21:10 -0800
>
> > On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote:
> >> * * *
> >>
> >> This series of VSOCK linux upstreaming patches include latest udpate from
> >> VMware to
On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote:
From: Greg KH gre...@linuxfoundation.org
Date: Tue, 8 Jan 2013 16:21:10 -0800
On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote:
* * *
This series of VSOCK linux upstreaming patches include latest udpate from
From: Dmitry Torokhov d...@vmware.com
Date: Tue, 08 Jan 2013 17:41:44 -0800
On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote:
From: Greg KH gre...@linuxfoundation.org
Date: Tue, 8 Jan 2013 16:21:10 -0800
On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote:
* * *
On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote:
From: Dmitry Torokhov d...@vmware.com
Date: Tue, 08 Jan 2013 17:41:44 -0800
On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote:
From: Greg KH gre...@linuxfoundation.org
Date: Tue, 8 Jan 2013 16:21:10 -0800
On
Hi Anthony,
> This was already done in a hypervisor neutral way using virtio:
>
> http://lists.openwall.net/netdev/2008/12/14/8
>
> The concept was Nacked and that led to the abomination of
> virtio-serial. If an address family for virtualization is on the
> table, we should reconsider
Hi Anthony,
This was already done in a hypervisor neutral way using virtio:
http://lists.openwall.net/netdev/2008/12/14/8
The concept was Nacked and that led to the abomination of
virtio-serial. If an address family for virtualization is on the
table, we should reconsider AF_VMCHANNEL.
On Thu, 2012-11-15 at 15:32 -0600, Anthony Liguori wrote:
>
> The concept was Nacked and that led to the abomination of virtio-serial. If
> an
> address family for virtualization is on the table, we should reconsider
> AF_VMCHANNEL.
>
> I'd be thrilled to get rid of virtio-serial...
Ack.
On Thu, 2012-11-15 at 15:32 -0600, Anthony Liguori wrote:
The concept was Nacked and that led to the abomination of virtio-serial. If
an
address family for virtualization is on the table, we should reconsider
AF_VMCHANNEL.
I'd be thrilled to get rid of virtio-serial...
Ack.
Ben.
On 11/07/2012 12:58 AM, Gerd Hoffmann wrote:
On 11/05/12 19:19, Andy King wrote:
Hi David,
The big and only question is whether anyone can actually use any of
this stuff without your proprietary bits?
Do you mean the VMCI calls? The VMCI driver is in the process of being
upstreamed into
On 11/07/2012 12:58 AM, Gerd Hoffmann wrote:
On 11/05/12 19:19, Andy King wrote:
Hi David,
The big and only question is whether anyone can actually use any of
this stuff without your proprietary bits?
Do you mean the VMCI calls? The VMCI driver is in the process of being
upstreamed into
Hi Sasha,
Thanks for taking a look.
> So all the documentation I see in the VMCI Socket Programming Guide
> is about userspace programming, and the documentation in af_vsock.c
> is all around implementation considerations.
Agreed, we're sorely lacking in proper documentation for the internal
Hi Sasha,
Thanks for taking a look.
So all the documentation I see in the VMCI Socket Programming Guide
is about userspace programming, and the documentation in af_vsock.c
is all around implementation considerations.
Agreed, we're sorely lacking in proper documentation for the internal
Hi Gerd,
>> Also, there was some interest from RedHat into using vSockets as
>> a unified interface, routed over a hypervisor-specific transport
>> (virtio or otherwise, although for now VMCI is the only one
>> implemented).
>
> Can you outline how this can be done? From a quick look over the
>
Hi Gerd,
Also, there was some interest from RedHat into using vSockets as
a unified interface, routed over a hypervisor-specific transport
(virtio or otherwise, although for now VMCI is the only one
implemented).
Can you outline how this can be done? From a quick look over the
code it
On 11/05/12 19:19, Andy King wrote:
> Hi David,
>
>> The big and only question is whether anyone can actually use any of
>> this stuff without your proprietary bits?
>
> Do you mean the VMCI calls? The VMCI driver is in the process of being
> upstreamed into the drivers/misc tree. Greg (cc'd
On 11/05/12 19:19, Andy King wrote:
Hi David,
The big and only question is whether anyone can actually use any of
this stuff without your proprietary bits?
Do you mean the VMCI calls? The VMCI driver is in the process of being
upstreamed into the drivers/misc tree. Greg (cc'd on these
Hi David,
> The big and only question is whether anyone can actually use any of
> this stuff without your proprietary bits?
Do you mean the VMCI calls? The VMCI driver is in the process of being
upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is
actively reviewing that code
Hi David,
The big and only question is whether anyone can actually use any of
this stuff without your proprietary bits?
Do you mean the VMCI calls? The VMCI driver is in the process of being
upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is
actively reviewing that code
28 matches
Mail list logo
