On Fri, Dec 04, 2015 at 11:49:18AM +0800, Stefan Hajnoczi wrote:
> Be explicit that the virtio_transport.ko code implements a draft virtio
> specification that is still subject to change.
> Signed-off-by: Stefan Hajnoczi
> If you'd rather wait until the device specification has been finalized, feel
> free to revert the virtio-vsock code for now. Apologies for not mentioning
> status in the Kconfig earlier.
> net/vmw_vsock/Kconfig | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> index 74e0bc8..d8be850 100644
> --- a/net/vmw_vsock/Kconfig
> +++ b/net/vmw_vsock/Kconfig
> @@ -28,12 +28,17 @@ config VMWARE_VMCI_VSOCKETS
> will be called vmw_vsock_vmci_transport. If unsure, say N.
> config VIRTIO_VSOCKETS
> - tristate "virtio transport for Virtual Sockets"
> + tristate "virtio transport for Virtual Sockets (Experimental)"
> depends on VSOCKETS && VIRTIO
> select VIRTIO_VSOCKETS_COMMON
> + default n
> This module implements a virtio transport for Virtual Sockets.
> + This feature is based on a draft of the virtio-vsock device
> + specification that is still subject to change. It can be used
> + to begin developing applications that use Virtual Sockets.
> Enable this transport if your Virtual Machine runs on Qemu/KVM.
> To compile this driver as a module, choose M here: the module
I'm pretty sure this alone is not enough. I think depending on an entry
under drivers/staging is necessary. The issue is userspace depending on
the interface, not kernel code itself being unstable. We can create
drivers/staging/virtio for this purpose, even if it's just to hold the
Kconfig entry. And I'd rather add STAGING within the KConfig names too,
so people enabling it don't get a surpise when their userspace stops
But yes, revert would be cleaner and easier than all this temporary
If you agree, could you send a patch to do one of these two things pls?
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html