Documentation for the NetLabel system, this includes a basic overview
of how NetLabel works, how LSM developers can integrate it into their
favorite LSM, as well as documentation on the CIPSO related sysctl
variables. Also, due to the difficulty of finding expired IETF
drafts, I am including the IETF CIPSO draft that is the basis of the
NetLabel CIPSO implementation.
Signed-off-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Update the index file with descriptions of the stable_api_nonsense.txt
and stable_kernel_rules.txt files.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Here's a document that describes the process and procedures of how to do Linux
kernel development. It has gone through a number of rounds of review on the
linux-kernel mailing list, and contains contributions and help from Paolo
Ciarrocchi, Randy Dunlap, Gerrit Huizenga, Pat Mochel, Hanna Linder, Kay
Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, David
A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch fixes the following spelling errors in Documentation/
- double "the"
- Several misspellings of function/functionality
- infomation
- memeory
- Recieved
- wether
and possibly others which I forgot ;-)
Trailing whitespaces on the same line as the typo are also deleted.
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add a new document describing the major kernel trees and how to apply their
patches.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch contains the documentation for the kexec based crash dump tool.
Quick kdump-howto
================================================================
1) Download and build kexec-tools.
2) Download and build the latest kexec/kdump (-mm) kernel patchset.
Two kernels need to be built in order to get this feature working.
A) First kernel:
a) Enable "kexec system call" feature:
CONFIG_KEXEC=y
b) Physical load address (use default):
CONFIG_PHYSICAL_START=0x100000
c) Enable "sysfs file system support":
CONFIG_SYSFS=y
d) Boot into first kernel with the command line parameter "crashkernel=Y@X":
For example: "crashkernel=64M@16M".
B) Second kernel:
a) Enable "kernel crash dumps" feature:
CONFIG_CRASH_DUMP=y
b) Physical load addreess, use same load address as X in "crashkernel"
kernel parameter in d) above, e.g., 16 MB or 0x1000000.
CONFIG_PHYSICAL_START=0x1000000
c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems).
CONFIG_PROC_VMCORE=y
3) Boot into the first kernel.
4) Load the second kernel to be booted using:
kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev>
maxcpus=1 init 1"
5) System reboots into the second kernel when a panic occurs. A module can be
written to force the panic, for testing purposes.
6) See Documentation/kdump.txt for how to read the first kernel's
memory image and how to analyze it.
Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com>
Signed-off-by: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: randy_dunlap <rdunlap@xenotime.net>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There's no longer a reason to document the obsolete BK usage.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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!
Paul Moore