|
|
|
#
|
|
|
|
# Makefile for the Linux TCP/IP (INET) layer.
|
|
|
|
#
|
|
|
|
|
|
|
|
obj-y := route.o inetpeer.o protocol.o \
|
|
|
|
ip_input.o ip_fragment.o ip_forward.o ip_options.o \
|
|
|
|
ip_output.o ip_sockglue.o inet_hashtables.o \
|
|
|
|
inet_timewait_sock.o inet_connection_sock.o \
|
|
|
|
tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
|
|
|
|
tcp_minisocks.o tcp_cong.o \
|
|
|
|
datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \
|
|
|
|
sysctl_net_ipv4.o fib_frontend.o fib_semantics.o
|
|
|
|
|
|
|
|
obj-$(CONFIG_IP_FIB_HASH) += fib_hash.o
|
|
|
|
obj-$(CONFIG_IP_FIB_TRIE) += fib_trie.o
|
|
|
|
obj-$(CONFIG_PROC_FS) += proc.o
|
|
|
|
obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
|
|
|
|
obj-$(CONFIG_IP_MROUTE) += ipmr.o
|
|
|
|
obj-$(CONFIG_NET_IPIP) += ipip.o
|
|
|
|
obj-$(CONFIG_NET_IPGRE) += ip_gre.o
|
|
|
|
obj-$(CONFIG_SYN_COOKIES) += syncookies.o
|
|
|
|
obj-$(CONFIG_INET_AH) += ah4.o
|
|
|
|
obj-$(CONFIG_INET_ESP) += esp4.o
|
|
|
|
obj-$(CONFIG_INET_IPCOMP) += ipcomp.o
|
|
|
|
obj-$(CONFIG_INET_XFRM_TUNNEL) += xfrm4_tunnel.o
|
|
|
|
obj-$(CONFIG_INET_TUNNEL) += tunnel4.o
|
|
|
|
obj-$(CONFIG_INET_XFRM_MODE_TRANSPORT) += xfrm4_mode_transport.o
|
|
|
|
obj-$(CONFIG_INET_XFRM_MODE_TUNNEL) += xfrm4_mode_tunnel.o
|
|
|
|
obj-$(CONFIG_IP_PNP) += ipconfig.o
|
|
|
|
obj-$(CONFIG_IP_ROUTE_MULTIPATH_RR) += multipath_rr.o
|
|
|
|
obj-$(CONFIG_IP_ROUTE_MULTIPATH_RANDOM) += multipath_random.o
|
|
|
|
obj-$(CONFIG_IP_ROUTE_MULTIPATH_WRANDOM) += multipath_wrandom.o
|
|
|
|
obj-$(CONFIG_IP_ROUTE_MULTIPATH_DRR) += multipath_drr.o
|
|
|
|
obj-$(CONFIG_NETFILTER) += netfilter.o netfilter/
|
|
|
|
obj-$(CONFIG_IP_VS) += ipvs/
|
[INET_DIAG]: Move the tcp_diag interface to the proper place
With this the previous setup is back, i.e. tcp_diag can be built as a module,
as dccp_diag and both share the infrastructure available in inet_diag.
If one selects CONFIG_INET_DIAG as module CONFIG_INET_TCP_DIAG will also be
built as a module, as will CONFIG_INET_DCCP_DIAG, if CONFIG_IP_DCCP was
selected static or as a module, if CONFIG_INET_DIAG is y, being statically
linked CONFIG_INET_TCP_DIAG will follow suit and CONFIG_INET_DCCP_DIAG will be
built in the same manner as CONFIG_IP_DCCP.
Now to aim at UDP, converting it to use inet_hashinfo, so that we can use
iproute2 for UDP sockets as well.
Ah, just to show an example of this new infrastructure working for DCCP :-)
[root@qemu ~]# ./ss -dane
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 0 *:5001 *:* ino:942 sk:cfd503a0
ESTAB 0 0 127.0.0.1:5001 127.0.0.1:32770 ino:943 sk:cfd50a60
ESTAB 0 0 127.0.0.1:32770 127.0.0.1:5001 ino:947 sk:cfd50700
TIME-WAIT 0 0 127.0.0.1:32769 127.0.0.1:5001 timer:(timewait,3.430ms,0) ino:0 sk:cf209620
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
20 years ago
|
|
|
obj-$(CONFIG_INET_DIAG) += inet_diag.o
|
|
|
|
obj-$(CONFIG_IP_ROUTE_MULTIPATH_CACHED) += multipath.o
|
[INET_DIAG]: Move the tcp_diag interface to the proper place
With this the previous setup is back, i.e. tcp_diag can be built as a module,
as dccp_diag and both share the infrastructure available in inet_diag.
If one selects CONFIG_INET_DIAG as module CONFIG_INET_TCP_DIAG will also be
built as a module, as will CONFIG_INET_DCCP_DIAG, if CONFIG_IP_DCCP was
selected static or as a module, if CONFIG_INET_DIAG is y, being statically
linked CONFIG_INET_TCP_DIAG will follow suit and CONFIG_INET_DCCP_DIAG will be
built in the same manner as CONFIG_IP_DCCP.
Now to aim at UDP, converting it to use inet_hashinfo, so that we can use
iproute2 for UDP sockets as well.
Ah, just to show an example of this new infrastructure working for DCCP :-)
[root@qemu ~]# ./ss -dane
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 0 *:5001 *:* ino:942 sk:cfd503a0
ESTAB 0 0 127.0.0.1:5001 127.0.0.1:32770 ino:943 sk:cfd50a60
ESTAB 0 0 127.0.0.1:32770 127.0.0.1:5001 ino:947 sk:cfd50700
TIME-WAIT 0 0 127.0.0.1:32769 127.0.0.1:5001 timer:(timewait,3.430ms,0) ino:0 sk:cf209620
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
20 years ago
|
|
|
obj-$(CONFIG_INET_TCP_DIAG) += tcp_diag.o
|
|
|
|
obj-$(CONFIG_NET_TCPPROBE) += tcp_probe.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_CUBIC) += tcp_cubic.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_highspeed.o
|
[TCP]: Add TCP Hybla congestion control module.
TCP Hybla congestion avoidance.
- "In heterogeneous networks, TCP connections that incorporate a
terrestrial or satellite radio link are greatly disadvantaged with
respect to entirely wired connections, because of their longer round
trip times (RTTs). To cope with this problem, a new TCP proposal, the
TCP Hybla, is presented and discussed in the paper[1]. It stems from an
analytical evaluation of the congestion window dynamics in the TCP
standard versions (Tahoe, Reno, NewReno), which suggests the necessary
modifications to remove the performance dependence on RTT.[...]"[1]
[1]: Carlo Caini, Rosario Firrincieli, "TCP Hybla: a TCP enhancement for
heterogeneous networks",
International Journal of Satellite Communications and Networking
Volume 22, Issue 5 , Pages 547 - 566. September 2004.
Signed-off-by: Daniele Lacamera (root at danielinux.net)net
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
20 years ago
|
|
|
obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
|
|
|
|
obj-$(CONFIG_TCP_CONG_COMPOUND) += tcp_compound.o
|
|
|
|
|
|
|
|
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
|
|
|
|
xfrm4_output.o
|