c996d8b9a8
Some of the documentation refers to web pages under the domain `osdl.org'. However, `osdl.org' now redirects to `linuxfoundation.org'. Rather than rely on redirections, this patch updates the addresses appropriately; for the most part, only documentation that is meant to be current has been updated. The patch should be pretty quick to scan and check; each new web-page url was gotten by trying out the original URL in a browser and then simply copying the the redirected URL (formatting as necessary). There is some conflict as to which one of these domain names is preferred: linuxfoundation.org linux-foundation.org So, I wrote: info@linuxfoundation.org and got this reply: Message-ID: <4CE17EE6.9040807@linuxfoundation.org> Date: Mon, 15 Nov 2010 10:41:42 -0800 From: David Ames <david@linuxfoundation.org> ... linuxfoundation.org is preferred. The canonical name for our web site is www.linuxfoundation.org. Our list site is actually lists.linux-foundation.org. Regarding email linuxfoundation.org is preferred there are a few people who choose to use linux-foundation.org for their own reasons. Consequently, I used `linuxfoundation.org' for web pages and `lists.linux-foundation.org' for mailing-list web pages and email addresses; the only personal email address I updated from `@osdl.org' was that of Andrew Morton, who prefers `linux-foundation.org' according `git log'. Signed-off-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
62 lines
1.7 KiB
Text
62 lines
1.7 KiB
Text
menuconfig IP_DCCP
|
|
tristate "The DCCP Protocol (EXPERIMENTAL)"
|
|
depends on INET && EXPERIMENTAL
|
|
---help---
|
|
Datagram Congestion Control Protocol (RFC 4340)
|
|
|
|
From http://www.ietf.org/rfc/rfc4340.txt:
|
|
|
|
The Datagram Congestion Control Protocol (DCCP) is a transport
|
|
protocol that implements bidirectional, unicast connections of
|
|
congestion-controlled, unreliable datagrams. It should be suitable
|
|
for use by applications such as streaming media, Internet telephony,
|
|
and on-line games.
|
|
|
|
To compile this protocol support as a module, choose M here: the
|
|
module will be called dccp.
|
|
|
|
If in doubt, say N.
|
|
|
|
if IP_DCCP
|
|
|
|
config INET_DCCP_DIAG
|
|
depends on INET_DIAG
|
|
def_tristate y if (IP_DCCP = y && INET_DIAG = y)
|
|
def_tristate m
|
|
|
|
source "net/dccp/ccids/Kconfig"
|
|
|
|
menu "DCCP Kernel Hacking"
|
|
depends on DEBUG_KERNEL=y
|
|
|
|
config IP_DCCP_DEBUG
|
|
bool "DCCP debug messages"
|
|
---help---
|
|
Only use this if you're hacking DCCP.
|
|
|
|
When compiling DCCP as a module, this debugging output can be toggled
|
|
by setting the parameter dccp_debug of the `dccp' module to 0 or 1.
|
|
|
|
Just say N.
|
|
|
|
config NET_DCCPPROBE
|
|
tristate "DCCP connection probing"
|
|
depends on PROC_FS && KPROBES
|
|
---help---
|
|
This module allows for capturing the changes to DCCP connection
|
|
state in response to incoming packets. It is used for debugging
|
|
DCCP congestion avoidance modules. If you don't understand
|
|
what was just said, you don't need it: say N.
|
|
|
|
Documentation on how to use DCCP connection probing can be found
|
|
at:
|
|
|
|
http://www.linuxfoundation.org/collaborate/workgroups/networking/dccpprobe
|
|
|
|
To compile this code as a module, choose M here: the
|
|
module will be called dccp_probe.
|
|
|
|
|
|
endmenu
|
|
|
|
endif # IP_DDCP
|