- 26 Apr, 2022 1 commit
-
-
Masami Hiramatsu authored
This allows kernel developer to embed a default bootconfig file in the kernel instead of embedding it in the initrd. This will be good for who are using the kernel without initrd, or who needs a default bootconfigs. This needs to set two kconfigs: CONFIG_BOOT_CONFIG_EMBED=y and set the file path to CONFIG_BOOT_CONFIG_EMBED_FILE. Note that you still need 'bootconfig' command line option to load the embedded bootconfig. Also if you boot using an initrd with a different bootconfig, the kernel will use the bootconfig in the initrd, instead of the default bootconfig. Link: https://lkml.kernel.org/r/164921227943.1090670.14035119557571329218.stgit@devnote2 Cc: Padmanabha Srinivasaiah <treasure4paddy@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org> Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org>
-
- 18 Oct, 2021 1 commit
-
-
Kees Cook authored
While the run-time testing of FORTIFY_SOURCE is already present in LKDTM, there is no testing of the expected compile-time detections. In preparation for correctly supporting FORTIFY_SOURCE under Clang, adding additional FORTIFY_SOURCE defenses, and making sure FORTIFY_SOURCE doesn't silently regress with GCC, introduce a build-time test suite that checks each expected compile-time failure condition. As this is relatively backwards from standard build rules in the sense that a successful test is actually a compile _failure_, create a wrapper script to check for the correct errors, and wire it up as a dummy dependency to lib/string.o, collecting the results into a log file artifact. Signed-off-by:
Kees Cook <keescook@chromium.org>
-
- 01 May, 2021 1 commit
-
-
Masahiro Yamada authored
The pattern prefixed with '/' matches files in the same directory, but not ones in sub-directories. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Acked-by:
Miguel Ojeda <ojeda@kernel.org> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
Andra Paraschiv <andraprs@amazon.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Gabriel Krisman Bertazi <krisman@collabora.com>
-
- 25 Mar, 2020 2 commits
-
-
Masahiro Yamada authored
Add SPDX License Identifier to all .gitignore files. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Masahiro Yamada authored
Some .gitignore files have comments like "Generated files", "Ignore generated files" at the header part, but they are too obvious. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 Aug, 2018 1 commit
-
-
Coly Li authored
Patch series "add crc64 calculation as kernel library", v5. This patchset adds basic implementation of crc64 calculation as a Linux kernel library. Since bcache already does crc64 by itself, this patchset also modifies bcache code to use the new crc64 library routine. Currently bcache is the only user of crc64 calculation, another potential user is bcachefs which is on the way to be in mainline kernel. Therefore it makes sense to make crc64 calculation to be a public library. bcache uses crc64 as storage checksum, if a change of crc lib routines results an inconsistent result, the unmatched checksum may make bcache 'think' the on-disk is corrupted, such a change should be avoided or detected as early as possible. Therefore a patch is being prepared which adds a crc test framework, to check consistency of different calculations. This patch (of 2): Add the re-write crc64 calculation routines for Linux kernel. The CRC64 polynomical arithmetic follows ECMA-182 spec...
-
- 08 Oct, 2012 1 commit
-
-
David Howells authored
Implement a simple static OID registry that allows the mapping of an encoded OID to an enum value for ease of use. The OID registry index enum appears in the: linux/oid_registry.h header file. A script generates the registry from lines in the header file that look like: <sp*>OID_foo,<sp*>/*<sp*>1.2.3.4<sp*>*/ The actual OID is taken to be represented by the numbers with interpolated dots in the comment. All other lines in the header are ignored. The registry is queries by calling: OID look_up_oid(const void *data, size_t datasize); This returns a number from the registry enum representing the OID if found or OID__NR if not. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au>
-
- 18 Oct, 2005 1 commit
-
-
Linus Torvalds authored
This still leaves driver and architecture-specific subdirectories alone, but gets rid of the bulk of the "generic" generated files that we should ignore. Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-