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
17 Nov, 2015
1 commit
-
Some architectures may want to override the default implementation
at compile time to do things inline. For example, ARM uses a
non-standard calling convention for better efficiency in this case.Signed-off-by: Nicolas Pitre
10 Nov, 2015
1 commit
-
Switch everything to the new and more capable implementation of abs().
Mainly to give the new abs() a bit of a workout.Cc: Michal Nazarewicz
Cc: John Stultz
Cc: Ingo Molnar
Cc: Steven Rostedt
Cc: Peter Zijlstra
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Mar, 2015
1 commit
-
The code refers to an invalid url
http://www.hackersdelight.org/HDcode/newCode/divDouble.c.txtThe correct url is
http://www.hackersdelight.org/hdcodetxt/divDouble.c.txtSigned-off-by: Heinrich Schuchardt
Signed-off-by: Jiri Kosina
23 Aug, 2013
1 commit
-
Commit f792685006274a850e6cc0ea9ade275ccdfc90bc ("math64: New
div64_u64_rem helper") implemented div64_u64 in terms of div64_u64_rem.
But div64_u64_rem was removed because it slowed down div64_u64 (and
there were no other users of div64_u64_rem).Device Mapper's I/O statistics support has a need for div64_u64_rem;
reintroduce this helper as a separate method that doesn't slow down
div64_u64, especially on 32-bit systems.Signed-off-by: Mike Snitzer
Cc: Stanislaw Gruszka
Cc: Ingo Molnar
Cc: Frederic Weisbecker
Cc: Mikulas Patocka
Signed-off-by: Alasdair G Kergon
01 May, 2013
1 commit
-
This reverts commit f792685006274a850e6cc0ea9ade275ccdfc90bc.
The cputime scaling code was changed/fixed and does not need the
div64_u64_rem() primitive anymore. It has no other users, so let's
remove them.Signed-off-by: Stanislaw Gruszka
Cc: Frederic Weisbecker
Cc: rostedt@goodmis.org
Cc: Linus Torvalds
Cc: Dave Hansen
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1367314507-9728-4-git-send-email-sgruszka@redhat.com
Signed-off-by: Ingo Molnar
14 Mar, 2013
1 commit
-
Provide an extended version of div64_u64() that
also returns the remainder of the division.We are going to need this to refine the cputime
scaling code.Signed-off-by: Frederic Weisbecker
Cc: Stanislaw Gruszka
Cc: Steven Rostedt
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Andrew Morton
28 Jun, 2012
1 commit
-
Signed-off-by: Akinobu Mita
Cc: Jiri Kosina
Signed-off-by: Jiri Kosina
08 Mar, 2012
1 commit
-
For files only using THIS_MODULE and/or EXPORT_SYMBOL, map
them onto including export.h -- or if the file isn't even
using those, then just delete the include. Fix up any implicit
include dependencies that were being masked by module.h along
the way.Signed-off-by: Paul Gortmaker
27 Oct, 2010
1 commit
-
The current implementation of div64_u64 for 32bit systems returns an
approximately correct result when the divisor exceeds 32bits. Since doing
64bit division using 32bit hardware is a long since solved problem we just
use one of the existing proven methods.Additionally, add a div64_s64 function to correctly handle doing signed
64bit division.Addresses https://bugzilla.redhat.com/show_bug.cgi?id=616105
Signed-off-by: Brian Behlendorf
Signed-off-by: Oleg Nesterov
Cc: Ben Woodard
Cc: Jeremy Fitzhardinge
Cc: Mark Grondona
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Jun, 2008
2 commits
-
iter_div_u64_rem is used in the x86-64 vdso, which cannot call other
kernel code. For this case, provide the always_inlined version,
__iter_div_u64_rem.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar -
We have a few instances of the open-coded iterative div/mod loop, used
when we don't expcet the dividend to be much bigger than the divisor.
Unfortunately modern gcc's have the tendency to strength "reduce" this
into a full mod operation, which isn't necessarily any faster, and
even if it were, doesn't exist if gcc implements it in libgcc.The workaround is to put a dummy asm statement in the loop to prevent
gcc from performing the transformation.This patch creates a single implementation of this loop, and uses it
to replace the open-coded versions I know about.Signed-off-by: Jeremy Fitzhardinge
Cc: Andrew Morton
Cc: john stultz
Cc: Segher Boessenkool
Cc: Christian Kujau
Cc: Robert Hancock
Signed-off-by: Ingo Molnar
01 May, 2008
2 commits
-
Rename div64_64 to div64_u64 to make it consistent with the other divide
functions, so it clearly includes the type of the divide. Move its definition
to math64.h as currently no architecture overrides the generic implementation.
They can still override it of course, but the duplicated declarations are
avoided.Signed-off-by: Roman Zippel
Cc: Avi Kivity
Cc: Russell King
Cc: Geert Uytterhoeven
Cc: Ralf Baechle
Cc: David Howells
Cc: Jeff Dike
Cc: Ingo Molnar
Cc: "David S. Miller"
Cc: Patrick McHardy
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The current do_div doesn't explicitly say that it's unsigned and the signed
counterpart is missing, which is e.g. needed when dealing with time values.This introduces 64bit signed/unsigned divide functions which also attempts to
cleanup the somewhat awkward calling API, which often requires the use of
temporary variables for the dividend. To avoid the need for temporary
variables everywhere for the remainder, each divide variant also provides a
version which doesn't return the remainder.Each architecture can now provide optimized versions of these function,
otherwise generic fallback implementations will be used.As an example I provided an alternative for the current x86 divide, which
avoids the asm casts and using an union allows gcc to generate better code.
It also avoids the upper divde in a few more cases, where the result is known
(i.e. upper quotient is zero).Signed-off-by: Roman Zippel
Cc: john stultz
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Apr, 2007
3 commits
-
Allow s390 to properly override the generic
__div64_32() implementation by:1) Using obj-y for div64.o in s390's makefile instead
of lib-y2) Adding the weak attribute to the generic implementation.
Signed-off-by: David S. Miller
-
Minor optimization of div64_64. do_div() already does optimization
for the case of 32 by 32 divide, so no need to do it here.Signed-off-by: Stephen Hemminger
Signed-off-by: David S. Miller -
Here is the current version of the 64 bit divide common code.
Signed-off-by: Stephen Hemminger
Signed-off-by: David S. Miller
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!
