02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
07 Dec, 2010
1 commit
-
This patch adds a generic infrastructure for policy-based dequeueing of
TX packets and provides two policies:
* a simple FIFO policy (which is the default) and
* a priority based policy (set via socket options).
Both policies honour the tx_qlen sysctl for the maximum size of the write
queue (can be overridden via socket options).The priority policy uses skb->priority internally to assign an u32 priority
identifier, using the same ranking as SO_PRIORITY. The skb->priority field
is set to 0 when the packet leaves DCCP. The priority is supplied as ancillary
data using cmsg(3), the patch also provides the requisite parsing routines.Signed-off-by: Tomasz Grobelny
Signed-off-by: Gerrit Renker
05 Jan, 2009
2 commits
-
This patch integrates the TFRC library, which is a dependency of CCID-3 (and
CCID-4), with the new use of CCIDs in the DCCP module.Signed-off-by: Gerrit Renker
Signed-off-by: David S. Miller -
Based on Arnaldo's earlier patch, this patch integrates the standardised
CCID congestion control plugins (CCID-2 and CCID-3) of DCCP with dccp.ko:* enables a faster connection path by eliminating the need to always go
through the CCID registration lock;* updates the implementation to use only a single array whose size equals
the number of configured CCIDs instead of the maximum (256);* since the CCIDs are now fixed array elements, synchronization is no
longer needed, simplifying use and implementation.CCID-2 is suggested as minimum for a basic DCCP implementation (RFC 4340, 10);
CCID-3 is a standards-track CCID supported by RFC 4342 and RFC 5348.Signed-off-by: Gerrit Renker
Signed-off-by: David S. Miller
03 Dec, 2006
1 commit
-
Resolves the problem that if IPv6 was configured `y' and DCCP `m' then
dccp_ipv6 was not built as a module. With this change, dccp_ipv6 is built
as a module whenever DCCP *OR* IPv6 are configured as modules; it will be
built-in only if both DCCP = `y' and IPV6 = `y'.Signed-off-by: Gerrit Renker
Signed-off-by: Arnaldo Carvalho de Melo
25 Sep, 2006
1 commit
-
This adds DCCP probing shamelessly ripped off from TCP probes by Stephen
Hemminger.I've put in here support for further CCID3 variables as well.
Andrea/Arnaldo might look to extend for CCID2.Signed-off-by: Ian McDonald
Signed-off-by: Arnaldo Carvalho de Melo
21 Mar, 2006
3 commits
-
With this patch in place we can break down the complexity by better
compartmentalizing the code that is common to ipv6 and ipv4.Now we have these modules:
Module Size Used by
dccp_diag 1344 0
inet_diag 9448 1 dccp_diag
dccp_ccid3 15856 0
dccp_tfrc_lib 12320 1 dccp_ccid3
dccp_ccid2 5764 0
dccp_ipv4 16996 2
dccp 48208 4 dccp_diag,dccp_ccid3,dccp_ccid2,dccp_ipv4dccp_ipv6 still requires dccp_ipv4 due to dccp_ipv6_mapped, that is
the next target to work on the "hey, ipv4 is legacy, I only want ipv6
dude!" direction.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
[root@qemu ~]# for a in /proc/sys/net/dccp/default/* ; do echo $a ; cat $a ; done
/proc/sys/net/dccp/default/ack_ratio
2
/proc/sys/net/dccp/default/rx_ccid
3
/proc/sys/net/dccp/default/send_ackvec
1
/proc/sys/net/dccp/default/send_ndp
1
/proc/sys/net/dccp/default/seq_window
100
/proc/sys/net/dccp/default/tx_ccid
3
[root@qemu ~]#So if wanting to test ccid3 as the tx CCID one can just do:
[root@qemu ~]# echo 3 > /proc/sys/net/dccp/default/tx_ccid
[root@qemu ~]# echo 2 > /proc/sys/net/dccp/default/rx_ccid
[root@qemu ~]# cat /proc/sys/net/dccp/default/[tr]x_ccid
2
3
[root@qemu ~]#Of course we also need the setsockopt for each app to tell its preferences, but
for testing or defining something other than CCID2 as the default for apps that
don't explicitely set their preference the sysctl interface is handy.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Still needs more work, but boots and doesn't crashes, even
does some negotiation!18:38:52.174934 127.0.0.1.43458 > 127.0.0.1.5001: request
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001::-)
Signed-off-by: Andrea Bittau
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
04 Jan, 2006
1 commit
-
Still needs mucho polishing, specially in the checksum code, but works
just fine, inet_diag/iproute2 and all 8)Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
18 Sep, 2005
1 commit
-
Isolating it, that will be used when we introduce a CCID2 (TCP-Like)
implementation.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
30 Aug, 2005
5 commits
-
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
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:cf209620Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Next changeset will rename tcp_diag to inet_diag and move the tcp_diag code out
of it and into a new tcp_diag.c, similar to the net/dccp/diag.c introduced in
this changeset, completing the transition to a generic inet_diag
infrastructure.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
This also changes the list_for_each_entry_safe_continue behaviour to match its
kerneldoc comment, that is, to start after the pos passed.Also adds several helper functions from previously open coded fragments, making
the code more clear.Signed-off-by: Arnaldo Carvalho de Melo
-
Development to this point was done on a subversion repository at:
http://oops.ghostprotocols.net:81/cgi-bin/viewcvs.cgi/dccp-2.6/
This repository will be kept at this site for the foreseable future,
so that interested parties can see the history of this code,
attributions, etc.If I ever decide to take this offline I'll provide the full history at
some other suitable place.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
