netdev - Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130109022204.GA22875@dtor-ws.eng.vmware.com>
Date:	Tue, 8 Jan 2013 18:22:04 -0800
From:	Dmitry Torokhov <dtor@...are.com>
To:	David Miller <davem@...emloft.net>
Cc:	pv-drivers@...are.com, gregkh@...uxfoundation.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote:
> From: Dmitry Torokhov <dtor@...are.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 <gregkh@...uxfoundation.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
> >> >> VMware to address Greg's and all other's code review comments.
> >> > 
> >> > Dave, you acked these patches a while ago,
> >> 
> >> Really?  I'd like to see where I did that.
> >> 
> >> 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&m=135301515818462&w=2
> > 
> > I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences
> > between the proposed solutions.
> 
> 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
hypervisors that implement either VMCI or virtio or something else
entirely.

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, and on this basis we ask to
include VSOCK.

Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html