Commit 65eaac59 authored by Tiwei Bie's avatar Tiwei Bie Committed by Johannes Berg
Browse files

um: Remove obsolete legacy network transports 



These legacy network transports were marked as obsolete in commit
40814b98 ("um: Mark non-vector net transports as obsolete").
More than five years have passed since then. Remove these network
transports to reduce the maintenance burden.

Suggested-by: default avatarAnton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: default avatarTiwei Bie <tiwei.btw@antgroup.com>
Acked-By: default avatarAnton Ivanov <anton.ivanov@cambridgegreys.com>
Link: https://patch.msgid.link/20250503051710.3286595-2-tiwei.btw@antgroup.com


Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
parent 304c9f7f

Documentation/virt/uml/user_mode_linux_howto_v2.rst

+2 −29
Original line number Diff line number Diff line
@@ -219,16 +219,6 @@ remote UML and other VM instances. 
+-----------+--------+------------------------------------+------------+

| vde       | vector | dep. on VDE VPN: Virt.Net Locator  | varies     |

+-----------+--------+------------------------------------+------------+

| tuntap    | legacy | none                               | ~ 500Mbit  |

+-----------+--------+------------------------------------+------------+

| daemon    | legacy | none                               | ~ 450Mbit  |

+-----------+--------+------------------------------------+------------+

| socket    | legacy | none                               | ~ 450Mbit  |

+-----------+--------+------------------------------------+------------+

| ethertap  | legacy | obsolete                           | ~ 500Mbit  |

+-----------+--------+------------------------------------+------------+

| vde       | legacy | obsolete                           | ~ 500Mbit  |

+-----------+--------+------------------------------------+------------+



* All transports which have tso and checksum offloads can deliver speeds

  approaching 10G on TCP streams.
@@ -236,27 +226,16 @@ remote UML and other VM instances. 
* All transports which have multi-packet rx and/or tx can deliver pps

  rates of up to 1Mps or more.



* All legacy transports are generally limited to ~600-700MBit and 0.05Mps.



* GRE and L2TPv3 allow connections to all of: local machine, remote

  machines, remote network devices and remote UML instances.



* Socket allows connections only between UML instances.



* Daemon and bess require running a local switch. This switch may be

  connected to the host as well.





Network configuration privileges

================================



The majority of the supported networking modes need ``root`` privileges.

For example, in the legacy tuntap networking mode, users were required

to be part of the group associated with the tunnel device.



For newer network drivers like the vector transports, ``root`` privilege

is required to fire an ioctl to setup the tun interface and/or use

raw sockets where needed.

For example, for vector transports, ``root`` privilege is required to fire

an ioctl to setup the tun interface and/or use raw sockets where needed.



This can be achieved by granting the user a particular capability instead

of running UML as root.  In case of vector transport, a user can add the
@@ -610,12 +589,6 @@ connect to a local area cloud (all the UML nodes using the same 
multicast address running on hosts in the same multicast domain (LAN)

will be automagically connected together to a virtual LAN.



Configuring Legacy transports

=============================



Legacy transports are now considered obsolete. Please use the vector

versions.



***********

Running UML

***********

arch/um/configs/i386_defconfig

+0 −6
Original line number Diff line number Diff line
@@ -53,12 +53,6 @@ CONFIG_UNIX=y 
CONFIG_INET=y

# CONFIG_IPV6 is not set

CONFIG_UML_NET=y

CONFIG_UML_NET_ETHERTAP=y

CONFIG_UML_NET_TUNTAP=y

CONFIG_UML_NET_SLIP=y

CONFIG_UML_NET_DAEMON=y

CONFIG_UML_NET_MCAST=y

CONFIG_UML_NET_SLIRP=y

CONFIG_EXT4_FS=y

CONFIG_QUOTA=y

CONFIG_AUTOFS_FS=m

arch/um/configs/x86_64_defconfig

+0 −6
Original line number Diff line number Diff line
@@ -52,12 +52,6 @@ CONFIG_UNIX=y 
CONFIG_INET=y

# CONFIG_IPV6 is not set

CONFIG_UML_NET=y

CONFIG_UML_NET_ETHERTAP=y

CONFIG_UML_NET_TUNTAP=y

CONFIG_UML_NET_SLIP=y

CONFIG_UML_NET_DAEMON=y

CONFIG_UML_NET_MCAST=y

CONFIG_UML_NET_SLIRP=y

CONFIG_EXT4_FS=y

CONFIG_QUOTA=y

CONFIG_AUTOFS_FS=m

arch/um/drivers/Kconfig

+0 −170
Original line number Diff line number Diff line
@@ -143,99 +143,6 @@ config UML_NET 
	  enable at least one of the following transport options to actually

	  make use of UML networking.



config UML_NET_ETHERTAP

	bool "Ethertap transport (obsolete)"

	depends on UML_NET

	help

	  The Ethertap User-Mode Linux network transport allows a single

	  running UML to exchange packets with its host over one of the

	  host's Ethertap devices, such as /dev/tap0.  Additional running

	  UMLs can use additional Ethertap devices, one per running UML.

	  While the UML believes it's on a (multi-device, broadcast) virtual

	  Ethernet network, it's in fact communicating over a point-to-point

	  link with the host.



	  To use this, your host kernel must have support for Ethertap

	  devices.  Also, if your host kernel is 2.4.x, it must have

	  CONFIG_NETLINK_DEV configured as Y or M.



	  For more information, see

	  <http://user-mode-linux.sourceforge.net/old/networking.html>  That site

	  has examples of the UML command line to use to enable Ethertap

	  networking.



	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please

	  migrate to UML_NET_VECTOR.



	  If unsure, say N.



config UML_NET_TUNTAP

	bool "TUN/TAP transport (obsolete)"

	depends on UML_NET

	help

	  The UML TUN/TAP network transport allows a UML instance to exchange

	  packets with the host over a TUN/TAP device.  This option will only

	  work with a 2.4 host, unless you've applied the TUN/TAP patch to

	  your 2.2 host kernel.



	  To use this transport, your host kernel must have support for TUN/TAP

	  devices, either built-in or as a module.



	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please

	  migrate to UML_NET_VECTOR.



	  If unsure, say N.



config UML_NET_SLIP

	bool "SLIP transport (obsolete)"

	depends on UML_NET

	help

	  The slip User-Mode Linux network transport allows a running UML to

	  network with its host over a point-to-point link.  Unlike Ethertap,

	  which can carry any Ethernet frame (and hence even non-IP packets),

	  the slip transport can only carry IP packets.



	  To use this, your host must support slip devices.



	  For more information, see

	  <http://user-mode-linux.sourceforge.net/old/networking.html>.

	  has examples of the UML command line to use to enable slip

	  networking, and details of a few quirks with it.



	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please

	  migrate to UML_NET_VECTOR.



	  If unsure, say N.



config UML_NET_DAEMON

	bool "Daemon transport (obsolete)"

	depends on UML_NET

	help

	  This User-Mode Linux network transport allows one or more running

	  UMLs on a single host to communicate with each other, but not to

	  the host.



	  To use this form of networking, you'll need to run the UML

	  networking daemon on the host.



	  For more information, see

	  <http://user-mode-linux.sourceforge.net/old/networking.html>  That site

	  has examples of the UML command line to use to enable Daemon

	  networking.



	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please

	  migrate to UML_NET_VECTOR.



	  If unsure, say N.



config UML_NET_DAEMON_DEFAULT_SOCK

	string "Default socket for daemon transport"

	default "/tmp/uml.ctl"

	depends on UML_NET_DAEMON

	help

	  This option allows setting the default socket for the daemon

	  transport, normally it defaults to /tmp/uml.ctl.



config UML_NET_VECTOR

	bool "Vector I/O high performance network devices"

	depends on UML_NET
@@ -248,83 +155,6 @@ config UML_NET_VECTOR 
	  with up to 4 times higher network throughput than the UML network

	  drivers.



config UML_NET_VDE

	bool "VDE transport (obsolete)"

	depends on UML_NET

	depends on !MODVERSIONS

	select MAY_HAVE_RUNTIME_DEPS

	help

	  This User-Mode Linux network transport allows one or more running

	  UMLs on a single host to communicate with each other and also

	  with the rest of the world using Virtual Distributed Ethernet,

	  an improved fork of uml_switch.



	  You must have libvdeplug installed in order to build the vde

	  transport into UML.



	  To use this form of networking, you will need to run vde_switch

	  on the host.



	  For more information, see <http://wiki.virtualsquare.org/>

	  That site has a good overview of what VDE is and also examples

	  of the UML command line to use to enable VDE networking.



	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please

	  migrate to UML_NET_VECTOR.



	  If unsure, say N.



config UML_NET_MCAST

	bool "Multicast transport (obsolete)"

	depends on UML_NET

	help

	  This Multicast User-Mode Linux network transport allows multiple

	  UMLs (even ones running on different host machines!) to talk to

	  each other over a virtual ethernet network.  However, it requires

	  at least one UML with one of the other transports to act as a

	  bridge if any of them need to be able to talk to their hosts or any

	  other IP machines.



	  To use this, your host kernel(s) must support IP Multicasting.



	  For more information, see

	  <http://user-mode-linux.sourceforge.net/old/networking.html>  That site

	  has examples of the UML command line to use to enable Multicast

	  networking, and notes about the security of this approach.



	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please

	  migrate to UML_NET_VECTOR.



	  If unsure, say N.



config UML_NET_SLIRP

	bool "SLiRP transport (obsolete)"

	depends on UML_NET

	help

	  The SLiRP User-Mode Linux network transport allows a running UML

	  to network by invoking a program that can handle SLIP encapsulated

	  packets.  This is commonly (but not limited to) the application

	  known as SLiRP, a program that can re-socket IP packets back onto

	  he host on which it is run.  Only IP packets are supported,

	  unlike other network transports that can handle all Ethernet

	  frames.  In general, slirp allows the UML the same IP connectivity

	  to the outside world that the host user is permitted, and unlike

	  other transports, SLiRP works without the need of root level

	  privileges, setuid binaries, or SLIP devices on the host.  This

	  also means not every type of connection is possible, but most

	  situations can be accommodated with carefully crafted slirp

	  commands that can be passed along as part of the network device's

	  setup string.  The effect of this transport on the UML is similar

	  that of a host behind a firewall that masquerades all network

	  connections passing through it (but is less secure).



	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please

	  migrate to UML_NET_VECTOR.



	  If unsure, say N.



	  Startup example: "eth0=slirp,FE:FD:01:02:03:04,/usr/local/bin/slirp"



endmenu



config VIRTIO_UML

arch/um/drivers/Makefile

+1 −17
Original line number Diff line number Diff line
@@ -6,11 +6,7 @@ 
# pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked

# in to pcap.o



slip-objs := slip_kern.o slip_user.o

slirp-objs := slirp_kern.o slirp_user.o

daemon-objs := daemon_kern.o daemon_user.o

vector-objs := vector_kern.o vector_user.o vector_transports.o

umcast-objs := umcast_kern.o umcast_user.o

net-objs := net_kern.o net_user.o

mconsole-objs := mconsole_kern.o mconsole_user.o

hostaudio-objs := hostaudio_kern.o
@@ -21,13 +17,6 @@ harddog-builtin-$(CONFIG_UML_WATCHDOG) := harddog_user.o harddog_user_exp.o 
rtc-objs := rtc_kern.o rtc_user.o

vfio_uml-objs := vfio_kern.o vfio_user.o



LDFLAGS_vde.o = $(shell $(CC) $(CFLAGS) -print-file-name=libvdeplug.a)



targets := vde_kern.o vde_user.o



$(obj)/vde.o: $(obj)/vde_kern.o $(obj)/vde_user.o

	$(LD) -r -dp -o $@ $^ $(ld_flags)



#XXX: The call below does not work because the flags are added before the

# object name, so nothing from the library gets linked.

#$(call if_changed,ld)
@@ -39,12 +28,7 @@ obj-y := stdio_console.o fd.o chan_kern.o chan_user.o line.o 
obj-$(CONFIG_SSL) += ssl.o

obj-$(CONFIG_STDERR_CONSOLE) += stderr_console.o



obj-$(CONFIG_UML_NET_SLIP) += slip.o slip_common.o

obj-$(CONFIG_UML_NET_SLIRP) += slirp.o slip_common.o

obj-$(CONFIG_UML_NET_DAEMON) += daemon.o 

obj-$(CONFIG_UML_NET_VECTOR) += vector.o

obj-$(CONFIG_UML_NET_VDE) += vde.o

obj-$(CONFIG_UML_NET_MCAST) += umcast.o

obj-$(CONFIG_UML_NET) += net.o 

obj-$(CONFIG_MCONSOLE) += mconsole.o

obj-$(CONFIG_MMAPPER) += mmapper_kern.o
@@ -66,7 +50,7 @@ obj-$(CONFIG_UML_PCI_OVER_VIRTIO) += virtio_pcidev.o 
obj-$(CONFIG_UML_PCI_OVER_VFIO) += vfio_uml.o



# pcap_user.o must be added explicitly.

USER_OBJS := fd.o null.o pty.o tty.o xterm.o slip_common.o vde_user.o vector_user.o

USER_OBJS := fd.o null.o pty.o tty.o xterm.o vector_user.o

CFLAGS_null.o = -DDEV_NULL=$(DEV_NULL_PATH)



CFLAGS_xterm.o += '-DCONFIG_XTERM_CHAN_DEFAULT_EMULATOR="$(CONFIG_XTERM_CHAN_DEFAULT_EMULATOR)"'