On Wed, 27 Sep 2017 13:42:01 +0200
Thomas Huth <[email protected]> wrote:
> There is no recent user space application available anymore which still
> supports this old virtio transport. Additionally, commit 3b2fbb3f06ef
> ("virtio/s390: deprecate old transport") introduced a deprecation message
> in the driver, and apparently nobody complained so far that it is still
> required. So let's simply remove it.
It has done its job of uncovering problems in QEMU's tcg code, so I
guess we can remove it :)
>
> Signed-off-by: Thomas Huth <[email protected]>
> ---
> arch/s390/Kconfig | 13 -
> drivers/s390/virtio/Makefile | 3 -
> drivers/s390/virtio/kvm_virtio.c | 515
> ---------------------------------------
> 3 files changed, 531 deletions(-)
> delete mode 100644 drivers/s390/virtio/kvm_virtio.c
>
> diff --git a/drivers/s390/virtio/Makefile b/drivers/s390/virtio/Makefile
> index df40692..d9942e0 100644
> --- a/drivers/s390/virtio/Makefile
> +++ b/drivers/s390/virtio/Makefile
> @@ -7,7 +7,4 @@
> # as published by the Free Software Foundation.
>
> s390-virtio-objs := virtio_ccw.o
> -ifdef CONFIG_S390_GUEST_OLD_TRANSPORT
> -s390-virtio-objs += kvm_virtio.o
> -endif
> obj-$(CONFIG_S390_GUEST) += $(s390-virtio-objs)
We could simplify this? Does not really matter, though.
This seems to be all of it (other than the uapi stuff).
I can apply this and submit it through virtio, but as I don't have
anything else queued, I would be fine with it going through the s390
architecture tree. In that case,
Reviewed-by: Cornelia Huck <[email protected]>
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
