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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ