Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

net: Fix Kconfig indentation, continued

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style. This fixes various indentation mixups (seven spaces,
tab+one space, etc).

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

authored by

Krzysztof Kozlowski and committed by
David S. Miller
43da1411 5421cf84

+147 -147
+13 -13
net/Kconfig
··· 258 258 default y 259 259 260 260 config HWBM 261 - bool 261 + bool 262 262 263 263 config CGROUP_NET_PRIO 264 264 bool "Network priority cgroup" ··· 309 309 select STREAM_PARSER 310 310 select NET_SOCK_MSG 311 311 ---help--- 312 - Enabling this allows a stream parser to be used with 313 - BPF_MAP_TYPE_SOCKMAP. 312 + Enabling this allows a stream parser to be used with 313 + BPF_MAP_TYPE_SOCKMAP. 314 314 315 - BPF_MAP_TYPE_SOCKMAP provides a map type to use with network sockets. 316 - It can be used to enforce socket policy, implement socket redirects, 317 - etc. 315 + BPF_MAP_TYPE_SOCKMAP provides a map type to use with network sockets. 316 + It can be used to enforce socket policy, implement socket redirects, 317 + etc. 318 318 319 319 config NET_FLOW_LIMIT 320 320 bool ··· 349 349 tristate "Network packet drop alerting service" 350 350 depends on INET && TRACEPOINTS 351 351 ---help--- 352 - This feature provides an alerting service to userspace in the 353 - event that packets are discarded in the network stack. Alerts 354 - are broadcast via netlink socket to any listening user space 355 - process. If you don't need network drop alerts, or if you are ok 356 - just checking the various proc files and other utilities for 357 - drop statistics, say N here. 352 + This feature provides an alerting service to userspace in the 353 + event that packets are discarded in the network stack. Alerts 354 + are broadcast via netlink socket to any listening user space 355 + process. If you don't need network drop alerts, or if you are ok 356 + just checking the various proc files and other utilities for 357 + drop statistics, say N here. 358 358 359 359 endmenu 360 360 ··· 433 433 imply NET_DROP_MONITOR 434 434 435 435 config PAGE_POOL 436 - bool 436 + bool 437 437 438 438 config FAILOVER 439 439 tristate "Generic failover module"
+109 -109
net/ipv4/Kconfig
··· 180 180 config NET_IPGRE_DEMUX 181 181 tristate "IP: GRE demultiplexer" 182 182 help 183 - This is helper module to demultiplex GRE packets on GRE version field criteria. 184 - Required by ip_gre and pptp modules. 183 + This is helper module to demultiplex GRE packets on GRE version field criteria. 184 + Required by ip_gre and pptp modules. 185 185 186 186 config NET_IP_TUNNEL 187 187 tristate ··· 459 459 tristate "Binary Increase Congestion (BIC) control" 460 460 default m 461 461 ---help--- 462 - BIC-TCP is a sender-side only change that ensures a linear RTT 463 - fairness under large windows while offering both scalability and 464 - bounded TCP-friendliness. The protocol combines two schemes 465 - called additive increase and binary search increase. When the 466 - congestion window is large, additive increase with a large 467 - increment ensures linear RTT fairness as well as good 468 - scalability. Under small congestion windows, binary search 469 - increase provides TCP friendliness. 470 - See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ 462 + BIC-TCP is a sender-side only change that ensures a linear RTT 463 + fairness under large windows while offering both scalability and 464 + bounded TCP-friendliness. The protocol combines two schemes 465 + called additive increase and binary search increase. When the 466 + congestion window is large, additive increase with a large 467 + increment ensures linear RTT fairness as well as good 468 + scalability. Under small congestion windows, binary search 469 + increase provides TCP friendliness. 470 + See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ 471 471 472 472 config TCP_CONG_CUBIC 473 473 tristate "CUBIC TCP" 474 474 default y 475 475 ---help--- 476 - This is version 2.0 of BIC-TCP which uses a cubic growth function 477 - among other techniques. 478 - See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf 476 + This is version 2.0 of BIC-TCP which uses a cubic growth function 477 + among other techniques. 478 + See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf 479 479 480 480 config TCP_CONG_WESTWOOD 481 481 tristate "TCP Westwood+" 482 482 default m 483 483 ---help--- 484 - TCP Westwood+ is a sender-side only modification of the TCP Reno 485 - protocol stack that optimizes the performance of TCP congestion 486 - control. It is based on end-to-end bandwidth estimation to set 487 - congestion window and slow start threshold after a congestion 488 - episode. Using this estimation, TCP Westwood+ adaptively sets a 489 - slow start threshold and a congestion window which takes into 490 - account the bandwidth used at the time congestion is experienced. 491 - TCP Westwood+ significantly increases fairness wrt TCP Reno in 492 - wired networks and throughput over wireless links. 484 + TCP Westwood+ is a sender-side only modification of the TCP Reno 485 + protocol stack that optimizes the performance of TCP congestion 486 + control. It is based on end-to-end bandwidth estimation to set 487 + congestion window and slow start threshold after a congestion 488 + episode. Using this estimation, TCP Westwood+ adaptively sets a 489 + slow start threshold and a congestion window which takes into 490 + account the bandwidth used at the time congestion is experienced. 491 + TCP Westwood+ significantly increases fairness wrt TCP Reno in 492 + wired networks and throughput over wireless links. 493 493 494 494 config TCP_CONG_HTCP 495 495 tristate "H-TCP" 496 496 default m 497 497 ---help--- 498 - H-TCP is a send-side only modifications of the TCP Reno 499 - protocol stack that optimizes the performance of TCP 500 - congestion control for high speed network links. It uses a 501 - modeswitch to change the alpha and beta parameters of TCP Reno 502 - based on network conditions and in a way so as to be fair with 503 - other Reno and H-TCP flows. 498 + H-TCP is a send-side only modifications of the TCP Reno 499 + protocol stack that optimizes the performance of TCP 500 + congestion control for high speed network links. It uses a 501 + modeswitch to change the alpha and beta parameters of TCP Reno 502 + based on network conditions and in a way so as to be fair with 503 + other Reno and H-TCP flows. 504 504 505 505 config TCP_CONG_HSTCP 506 506 tristate "High Speed TCP" 507 507 default n 508 508 ---help--- 509 - Sally Floyd's High Speed TCP (RFC 3649) congestion control. 510 - A modification to TCP's congestion control mechanism for use 511 - with large congestion windows. A table indicates how much to 512 - increase the congestion window by when an ACK is received. 513 - For more detail see http://www.icir.org/floyd/hstcp.html 509 + Sally Floyd's High Speed TCP (RFC 3649) congestion control. 510 + A modification to TCP's congestion control mechanism for use 511 + with large congestion windows. A table indicates how much to 512 + increase the congestion window by when an ACK is received. 513 + For more detail see http://www.icir.org/floyd/hstcp.html 514 514 515 515 config TCP_CONG_HYBLA 516 516 tristate "TCP-Hybla congestion control algorithm" 517 517 default n 518 518 ---help--- 519 - TCP-Hybla is a sender-side only change that eliminates penalization of 520 - long-RTT, large-bandwidth connections, like when satellite legs are 521 - involved, especially when sharing a common bottleneck with normal 522 - terrestrial connections. 519 + TCP-Hybla is a sender-side only change that eliminates penalization of 520 + long-RTT, large-bandwidth connections, like when satellite legs are 521 + involved, especially when sharing a common bottleneck with normal 522 + terrestrial connections. 523 523 524 524 config TCP_CONG_VEGAS 525 525 tristate "TCP Vegas" 526 526 default n 527 527 ---help--- 528 - TCP Vegas is a sender-side only change to TCP that anticipates 529 - the onset of congestion by estimating the bandwidth. TCP Vegas 530 - adjusts the sending rate by modifying the congestion 531 - window. TCP Vegas should provide less packet loss, but it is 532 - not as aggressive as TCP Reno. 528 + TCP Vegas is a sender-side only change to TCP that anticipates 529 + the onset of congestion by estimating the bandwidth. TCP Vegas 530 + adjusts the sending rate by modifying the congestion 531 + window. TCP Vegas should provide less packet loss, but it is 532 + not as aggressive as TCP Reno. 533 533 534 534 config TCP_CONG_NV 535 - tristate "TCP NV" 536 - default n 537 - ---help--- 538 - TCP NV is a follow up to TCP Vegas. It has been modified to deal with 539 - 10G networks, measurement noise introduced by LRO, GRO and interrupt 540 - coalescence. In addition, it will decrease its cwnd multiplicatively 541 - instead of linearly. 535 + tristate "TCP NV" 536 + default n 537 + ---help--- 538 + TCP NV is a follow up to TCP Vegas. It has been modified to deal with 539 + 10G networks, measurement noise introduced by LRO, GRO and interrupt 540 + coalescence. In addition, it will decrease its cwnd multiplicatively 541 + instead of linearly. 542 542 543 - Note that in general congestion avoidance (cwnd decreased when # packets 544 - queued grows) cannot coexist with congestion control (cwnd decreased only 545 - when there is packet loss) due to fairness issues. One scenario when they 546 - can coexist safely is when the CA flows have RTTs << CC flows RTTs. 543 + Note that in general congestion avoidance (cwnd decreased when # packets 544 + queued grows) cannot coexist with congestion control (cwnd decreased only 545 + when there is packet loss) due to fairness issues. One scenario when they 546 + can coexist safely is when the CA flows have RTTs << CC flows RTTs. 547 547 548 - For further details see http://www.brakmo.org/networking/tcp-nv/ 548 + For further details see http://www.brakmo.org/networking/tcp-nv/ 549 549 550 550 config TCP_CONG_SCALABLE 551 551 tristate "Scalable TCP" 552 552 default n 553 553 ---help--- 554 - Scalable TCP is a sender-side only change to TCP which uses a 555 - MIMD congestion control algorithm which has some nice scaling 556 - properties, though is known to have fairness issues. 557 - See http://www.deneholme.net/tom/scalable/ 554 + Scalable TCP is a sender-side only change to TCP which uses a 555 + MIMD congestion control algorithm which has some nice scaling 556 + properties, though is known to have fairness issues. 557 + See http://www.deneholme.net/tom/scalable/ 558 558 559 559 config TCP_CONG_LP 560 560 tristate "TCP Low Priority" 561 561 default n 562 562 ---help--- 563 - TCP Low Priority (TCP-LP), a distributed algorithm whose goal is 564 - to utilize only the excess network bandwidth as compared to the 565 - ``fair share`` of bandwidth as targeted by TCP. 566 - See http://www-ece.rice.edu/networks/TCP-LP/ 563 + TCP Low Priority (TCP-LP), a distributed algorithm whose goal is 564 + to utilize only the excess network bandwidth as compared to the 565 + ``fair share`` of bandwidth as targeted by TCP. 566 + See http://www-ece.rice.edu/networks/TCP-LP/ 567 567 568 568 config TCP_CONG_VENO 569 569 tristate "TCP Veno" 570 570 default n 571 571 ---help--- 572 - TCP Veno is a sender-side only enhancement of TCP to obtain better 573 - throughput over wireless networks. TCP Veno makes use of state 574 - distinguishing to circumvent the difficult judgment of the packet loss 575 - type. TCP Veno cuts down less congestion window in response to random 576 - loss packets. 577 - See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186> 572 + TCP Veno is a sender-side only enhancement of TCP to obtain better 573 + throughput over wireless networks. TCP Veno makes use of state 574 + distinguishing to circumvent the difficult judgment of the packet loss 575 + type. TCP Veno cuts down less congestion window in response to random 576 + loss packets. 577 + See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186> 578 578 579 579 config TCP_CONG_YEAH 580 580 tristate "YeAH TCP" 581 581 select TCP_CONG_VEGAS 582 582 default n 583 583 ---help--- 584 - YeAH-TCP is a sender-side high-speed enabled TCP congestion control 585 - algorithm, which uses a mixed loss/delay approach to compute the 586 - congestion window. It's design goals target high efficiency, 587 - internal, RTT and Reno fairness, resilience to link loss while 588 - keeping network elements load as low as possible. 584 + YeAH-TCP is a sender-side high-speed enabled TCP congestion control 585 + algorithm, which uses a mixed loss/delay approach to compute the 586 + congestion window. It's design goals target high efficiency, 587 + internal, RTT and Reno fairness, resilience to link loss while 588 + keeping network elements load as low as possible. 589 589 590 - For further details look here: 591 - http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf 590 + For further details look here: 591 + http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf 592 592 593 593 config TCP_CONG_ILLINOIS 594 594 tristate "TCP Illinois" 595 595 default n 596 596 ---help--- 597 - TCP-Illinois is a sender-side modification of TCP Reno for 598 - high speed long delay links. It uses round-trip-time to 599 - adjust the alpha and beta parameters to achieve a higher average 600 - throughput and maintain fairness. 597 + TCP-Illinois is a sender-side modification of TCP Reno for 598 + high speed long delay links. It uses round-trip-time to 599 + adjust the alpha and beta parameters to achieve a higher average 600 + throughput and maintain fairness. 601 601 602 - For further details see: 603 - http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html 602 + For further details see: 603 + http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html 604 604 605 605 config TCP_CONG_DCTCP 606 606 tristate "DataCenter TCP (DCTCP)" 607 607 default n 608 608 ---help--- 609 - DCTCP leverages Explicit Congestion Notification (ECN) in the network to 610 - provide multi-bit feedback to the end hosts. It is designed to provide: 609 + DCTCP leverages Explicit Congestion Notification (ECN) in the network to 610 + provide multi-bit feedback to the end hosts. It is designed to provide: 611 611 612 - - High burst tolerance (incast due to partition/aggregate), 613 - - Low latency (short flows, queries), 614 - - High throughput (continuous data updates, large file transfers) with 615 - commodity, shallow-buffered switches. 612 + - High burst tolerance (incast due to partition/aggregate), 613 + - Low latency (short flows, queries), 614 + - High throughput (continuous data updates, large file transfers) with 615 + commodity, shallow-buffered switches. 616 616 617 - All switches in the data center network running DCTCP must support 618 - ECN marking and be configured for marking when reaching defined switch 619 - buffer thresholds. The default ECN marking threshold heuristic for 620 - DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets 621 - (~100KB) at 10Gbps, but might need further careful tweaking. 617 + All switches in the data center network running DCTCP must support 618 + ECN marking and be configured for marking when reaching defined switch 619 + buffer thresholds. The default ECN marking threshold heuristic for 620 + DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets 621 + (~100KB) at 10Gbps, but might need further careful tweaking. 622 622 623 - For further details see: 624 - http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf 623 + For further details see: 624 + http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf 625 625 626 626 config TCP_CONG_CDG 627 627 tristate "CAIA Delay-Gradient (CDG)" 628 628 default n 629 629 ---help--- 630 - CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies 631 - the TCP sender in order to: 630 + CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies 631 + the TCP sender in order to: 632 632 633 633 o Use the delay gradient as a congestion signal. 634 634 o Back off with an average probability that is independent of the RTT. 635 635 o Coexist with flows that use loss-based congestion control. 636 636 o Tolerate packet loss unrelated to congestion. 637 637 638 - For further details see: 639 - D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using 640 - delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg 638 + For further details see: 639 + D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using 640 + delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg 641 641 642 642 config TCP_CONG_BBR 643 643 tristate "BBR TCP" 644 644 default n 645 645 ---help--- 646 646 647 - BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to 648 - maximize network utilization and minimize queues. It builds an explicit 649 - model of the the bottleneck delivery rate and path round-trip 650 - propagation delay. It tolerates packet loss and delay unrelated to 651 - congestion. It can operate over LAN, WAN, cellular, wifi, or cable 652 - modem links. It can coexist with flows that use loss-based congestion 653 - control, and can operate with shallow buffers, deep buffers, 654 - bufferbloat, policers, or AQM schemes that do not provide a delay 655 - signal. It requires the fq ("Fair Queue") pacing packet scheduler. 647 + BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to 648 + maximize network utilization and minimize queues. It builds an explicit 649 + model of the the bottleneck delivery rate and path round-trip 650 + propagation delay. It tolerates packet loss and delay unrelated to 651 + congestion. It can operate over LAN, WAN, cellular, wifi, or cable 652 + modem links. It can coexist with flows that use loss-based congestion 653 + control, and can operate with shallow buffers, deep buffers, 654 + bufferbloat, policers, or AQM schemes that do not provide a delay 655 + signal. It requires the fq ("Fair Queue") pacing packet scheduler. 656 656 657 657 choice 658 658 prompt "Default TCP congestion control"
+13 -13
net/ipv6/netfilter/Kconfig
··· 128 128 depends on NETFILTER_ADVANCED 129 129 select NETFILTER_XT_MATCH_HL 130 130 ---help--- 131 - This is a backwards-compat option for the user's convenience 132 - (e.g. when running oldconfig). It selects 133 - CONFIG_NETFILTER_XT_MATCH_HL. 131 + This is a backwards-compat option for the user's convenience 132 + (e.g. when running oldconfig). It selects 133 + CONFIG_NETFILTER_XT_MATCH_HL. 134 134 135 135 config IP6_NF_MATCH_IPV6HEADER 136 136 tristate '"ipv6header" IPv6 Extension Headers Match' ··· 184 184 depends on NETFILTER_ADVANCED && IP6_NF_MANGLE 185 185 select NETFILTER_XT_TARGET_HL 186 186 ---help--- 187 - This is a backwards-compatible option for the user's convenience 188 - (e.g. when running oldconfig). It selects 189 - CONFIG_NETFILTER_XT_TARGET_HL. 187 + This is a backwards-compatible option for the user's convenience 188 + (e.g. when running oldconfig). It selects 189 + CONFIG_NETFILTER_XT_TARGET_HL. 190 190 191 191 config IP6_NF_FILTER 192 192 tristate "Packet filtering" ··· 245 245 246 246 # security table for MAC policy 247 247 config IP6_NF_SECURITY 248 - tristate "Security table" 249 - depends on SECURITY 250 - depends on NETFILTER_ADVANCED 251 - help 252 - This option adds a `security' table to iptables, for use 253 - with Mandatory Access Control (MAC) policy. 248 + tristate "Security table" 249 + depends on SECURITY 250 + depends on NETFILTER_ADVANCED 251 + help 252 + This option adds a `security' table to iptables, for use 253 + with Mandatory Access Control (MAC) policy. 254 254 255 - If unsure, say N. 255 + If unsure, say N. 256 256 257 257 config IP6_NF_NAT 258 258 tristate "ip6tables NAT support"
+7 -7
net/nfc/hci/Kconfig
··· 1 1 # SPDX-License-Identifier: GPL-2.0-only 2 2 config NFC_HCI 3 - depends on NFC 4 - tristate "NFC HCI implementation" 5 - default n 6 - help 7 - Say Y here if you want to build support for a kernel NFC HCI 8 - implementation. This is mostly needed for devices that only process 9 - HCI frames, like for example the NXP pn544. 3 + depends on NFC 4 + tristate "NFC HCI implementation" 5 + default n 6 + help 7 + Say Y here if you want to build support for a kernel NFC HCI 8 + implementation. This is mostly needed for devices that only process 9 + HCI frames, like for example the NXP pn544. 10 10 11 11 config NFC_SHDLC 12 12 depends on NFC_HCI
+5 -5
net/xfrm/Kconfig
··· 3 3 # XFRM configuration 4 4 # 5 5 config XFRM 6 - bool 7 - depends on INET 8 - select GRO_CELLS 9 - select SKB_EXTENSIONS 6 + bool 7 + depends on INET 8 + select GRO_CELLS 9 + select SKB_EXTENSIONS 10 10 11 11 config XFRM_OFFLOAD 12 - bool 12 + bool 13 13 14 14 config XFRM_ALGO 15 15 tristate