27 Jul, 2018
1 commit
-
Allow other drivers and parts of kernel to use the same define for
CRC32 polynomial, instead of duplicating it in many places. This code
does not bring any functional changes, except moving existing code.Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Herbert Xu
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
24 Mar, 2012
5 commits
-
Allow the kernel builder to choose a crc32* algorithm for the kernel.
Signed-off-by: Darrick J. Wong
Cc: Bob Pearson
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Reuse the existing crc32 code to stamp out a crc32c implementation.
Signed-off-by: Darrick J. Wong
Cc: Herbert Xu
Cc: Bob Pearson
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add slicing-by-8 algorithm to the existing slicing-by-4 algorithm. This
consists of:- extend largest BITS size from 32 to 64
- extend tables from tab[4][256] to up to tab[8][256]
- Add code for inner loop.[djwong@us.ibm.com: Minor changelog tweaks]
Signed-off-by: Bob Pearson
Signed-off-by: Darrick J. Wong
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
crc32.c provides a choice of one of several algorithms for computing the
LSB and LSB versions of the CRC32 checksum based on the parameters
CRC_LE_BITS and CRC_BE_BITS.In the original version the values 1, 2, 4 and 8 respectively selected
versions of the alrogithm that computed the crc 1, 2, 4 and 32 bits as a
time.This patch series adds a new version that computes the CRC 64 bits at a
time. To make things easier to understand the parameter has been
reinterpreted to actually stand for the number of bits processed in each
step of the algorithm so that the old value 8 has been replaced with the
value 32.This also allows us to add in a widely used crc algorithm that computes
the crc 8 bits at a time called the Sarwate algorithm.[djwong@us.ibm.com: Minor changelog tweaks]
Signed-off-by: Bob Pearson
Signed-off-by: Darrick J. Wong
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patchset (re)uses Bob Pearson's crc32 slice-by-8 code to stamp out
a software crc32c implementation. It removes the crc32c implementation
in crypto/ in favor of using the stamped-out one in lib/. There is also
a change to Kconfig so that the kernel builder can pick an
implementation best suited for the hardware.The motivation for this patchset is that I am working on adding full
metadata checksumming to ext4. As far as performance impact of adding
checksumming goes, I see nearly no change with a standard mail server
ffsb simulation. On a test that involves only file creation and
deletion and extent tree writes, I see a drop of about 50 pcercent with
the current kernel crc32c implementation; this improves to a drop of
about 20 percent with the enclosed crc32c code.When metadata is usually a small fraction of total IO, this new
implementation doesn't help much because metadata is usually a small
fraction of total IO. However, when we are doing IO that is almost all
metadata (such as rm -rf'ing a tree), then this patch speeds up the
operation substantially.Incidentally, given that iscsi, sctp, and btrfs also use crc32c, this
patchset should improve their speed as well. I have not yet quantified
that, however. This latest submission combines Bob's patches from late
August 2011 with mine so that they can be one coherent patch set.
Please excuse my inability to combine some of the patches; I've been
advised to leave Bob's patches alone and build atop them instead. :/Since the last posting, I've also collected some crc32c test results on
a bunch of different x86/powerpc/sparc platforms. The results can be
viewed here: http://goo.gl/sgt3i ; the "crc32-kern-le" and "crc32c"
columns describe the performance of the kernel's current crc32 and
crc32c software implementations. The "crc32c-by8-le" column shows
crc32c performance with this patchset applied. I expect crc32
performance to be roughly the same.The two _boost columns at the right side of the spreadsheet shows how much
faster the new implementation is over the old one. As you can see, crc32
rises substantially, and crc32c experiences a huge increase.This patch:
- remove trailing whitespace from lib/crc32.c
- remove trailing whitespace from lib/crc32defs.h[djwong@us.ibm.com: changelog tweaks]
Signed-off-by: Bob Pearson
Signed-off-by: Darrick J. Wong
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
