OLS: Kernel documentation, and submitting kernel patches


 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements UNIX and Linux RSS News OLS: Kernel documentation, and submitting kernel patches
# 1  
Old 07-25-2008
OLS: Kernel documentation, and submitting kernel patches

07-25-2008 08:00 AM
The second of four days at the 10th annual Ottawa Linux Symposium got off to an unusual start as a small bird "assisted" Rob Landley in giving the first talk I attended, called "Where Linux kernel documentation hides." The tweeting bird was polite, only flying over the audience a couple of times and mostly paying attention.



Source...
Login or Register to Ask a Question

Previous Thread | Next Thread

9 More Discussions You Might Find Interesting

1. Red Hat

Problems with kernel patches

Three RH7 servers patched through a satellite and rebooted Sunday. Two of the three experienced issues with kernel 123.20.1 and were reporting logind and systemd errors, org.freedesktop subscription failure. Users ssh'ing into the two servers had to wait 30 seconds to get the password prompt.... (2 Replies)
Discussion started by: cjhilinski
2 Replies

2. Linux

Unload kernel module at boot time (Debian Wheezy 7.2, 3.2.0-4-686-pae kernel)

Hi everyone, I am trying to prevent the ehci_hcd kernel module to load at boot time. Here's what I've tried so far: 1) Add the following line to /etc/modprobe.d/blacklist.conf (as suggested here): 2) Blacklisted the module by adding the following string to 3) Tried to blacklist the module... (0 Replies)
Discussion started by: gacanepa
0 Replies

3. Solaris

how to update the kernel patches in solaris 10

tell me the step by step procedure for updating the kernel patches in solaris 10. (1 Reply)
Discussion started by: tv.praveenkumar
1 Replies

4. Solaris

Which file is read by kernel to set its default system kernel parameters values?

Hi gurus Could anybody tell me which file is read by kernel to set its default system kernal parameters values in solaris. Here I am not taking about /etc/system file which is used to load kernal modules or to change any default system kernal parameter value Is it /dev/kmem file or something... (1 Reply)
Discussion started by: girish.batra
1 Replies

5. Linux

Supermicro(dual core) server getting rebooted after "decompressing the kernel;booting the kernel" me

supermicro(dual core) server getting rebooted after "decompressing the kernel;booting the kernel" message comes. I tried giving acpi=off to the kernel command line but same problem.It shows everything ok and no problem with memory and processors and power supplies.Wt could be the reason? It has... (1 Reply)
Discussion started by: pankajd
1 Replies

6. SuSE

max number of slabs per kernel module (kernel 2.6.17, suse)

Hi All, Is there a max number of slabs that can be used per kernel module? I'm having a tough time finding out that kind of information, but the array 'node_zonelists' (mmzone.h) has a size of 5. I just want to avoid buffer overruns and other bad stuff. Cheers, Brendan (4 Replies)
Discussion started by: Brendan Kennedy
4 Replies

7. Programming

kernel-kernel call communication

hi all! i have developed a mechanism in system.c to count how many times each kernel call is called. The results are held in an array in system.c . What i want to do is to create a new kernel call which will print this array. I need help in passing the array from system.c to the new kernel call. ... (5 Replies)
Discussion started by: aureliano
5 Replies

8. Linux

Kernel panic - not syncing: cannot execute a PAE-enabled kernel on PAE-less CPU

ok so I just installed fedora core 6 on my dell inspiron 700m and I go to boot into linux and I get this error. Has anyone seen this before? I also had XP Pro and Vista installed on this pc prior to putting fedora core 6 on the machine. I'm trying to setup a triple boot system. Please Help... (2 Replies)
Discussion started by: dave043
2 Replies

9. HP-UX

kernel, memory and patches information

I kind of forget easily. Is anyone remember the command to find kernel, memory and patches information of HPUX 11.0 machine? Thank you! (0 Replies)
Discussion started by: Teh Tiack Ein
0 Replies
Login or Register to Ask a Question
PATCHER(1)                                              User Contributed Perl Documentation                                             PATCHER(1)

NAME
patcher - a patch maintenance tool SYNOPSIS
patcher [-n <patchname>] [<file ...>] Edit <file> as part of the patch <patchname>. patcher -r Refresh current patch. patcher [-f] -b Move back one patch to the previous one. patcher [-f] -b <patch> Move back in series until we're at <patch>. patcher [-f] -b <num> Move back <num> patches in series. patcher -a Apply the next patch in the series. patcher -a <patch> Apply all patches from the series until we've reached at <patch>. patcher -a <num> Apply next <num> patches from series. patcher -n <patchname> [-p <n>] -i <diff> Import an external diff file into patch <patchname>. Strip <n> levels from the directory names. Please note that patch allows '-p1', but we only '-p 1'. patcher [-f] [-n <patchname>] [-p <n>] -i <patch ...> Import an external diff file into patch <patchname>. Strip <n> levels from the directory names. Please note that patch allows '-p1', but we only '-p 1'. CONCEPT
Patcher is a perl script which I use for managing patches. It's quite powerful, easy to use, and fast. Patcher keeps track of which files you change. It then can generate patches from your changes, no need for you to handle the diff tool man- ually. You can have more than one record of file changes, we call this a patch. A patch is something that the patch(1) command can apply. The patches can be stacked in series, they define the order they have to applied. Patcher keeps series information as well as information which patches have been applied and which not. DESCRIPTION
Later we will have a walkthrought, but let me first explain the basic operation modes of patcher: Editing files When you call patcher with a filename, patch will make a backup of this file (if the file exists). Now you can create or change the file. Later you can ask patcher to create a unified diff with all your changes. Creating unified diffs Just call "patcher -r" and you will get a unified diff of all your additions, modification and deletions. The diff will be stored in .patches/<patchname>.patch. It is in a form that allows direct application via patch(1) or, of course, via "patcher -i". Whenever you do "patcher -r" your .patches/<patchname>.patch file get's refreshed. Back out a patch To revoke your changes and go to the previous version, just enter "patcher -b". Patcher will make sure that you don't loose your changes by asking you to create a diff if something has changed since the last refresh. You may use -f (or --force) patcher to go back anyway. You can back out more than one patch by either specifying a number a patch name after -b. Re-Apply a patch With "patcher -n <patchname> -a" one can apply an already existing managed patch. A managed patch is a patch that already is stored in the .patches directory and is mentioned in the .patches/series file. Patcher tests if the patch would apply without problem and applies it. If the patch would be rejected, you can use -f (or --force) to apply the patch anyway. You can apply more than one patch by either specifying a number a patch name after -a. Importing external patches Sometimes you have an external patch. That's the opposite of a managed patch, the patch is not stored in the .patches directory. By import- ing it, it will become a managed patch. Import the patch simply with -i <filename>. You can use -p <num> to specify the directory level, similar to the -p<num> option of patch(1). But please keep in mind that we need a space between -p and the number. Normally only clean patches will be imported. To import a patch that creates rejects use -f (or --force). You'll see a list of files where the patch did not apply cleanly, fix the problems manually. Later you can use "patcher -r" to create a clean patch. INSTALLATION
Just place patcher somewhere in your path. That's all. For each project Patcher requires one special directory called ".patches". It will search for this directory. If it does not exist, patcher creates it automatically. INTERNALS
All work occurs with a single directory tree. All commands are invoked within the root of that tree (TODO: this can and should change). Patcher manages a "stack" of patches. Each patch is a changeset against the base tree plus the preceding patches. All patches are listed, in order, in the file ".patches/series". Patcher adds patches into this file, but never deletes entries. You can edit this file with a text editor, but please do only so if the patch you delete is currently not applied. Any currently applied patches is listed in the file ".patches/applied". The patcher manage this file, there is no need for you to ever edit this file manually. Each patch affects a number of files in the tree. These files are listed in a file list named ".patches/*.files". Patcher manages them. When you back out a patch, this file will deleted. Or, in other words, this file exists only for applied patches. It's only used by "patcher -r". Patches are placed into ".patches/*.patch" files. They are always unified diffs with -p1 as patchlevel. You can copy then anywhere, the patch(1) utility will read them without problems. Optionally you can put descriptions for the patches in files named ".patches/*.txt". So for a particular patch "my-first-patch" the following will exist: - An entry "my-first-patch.patch" in ".patches/series". - An entry "my-first-patch" in ".patches/applied" (if it's currently applied) - A file ".patches/my-first-patch.files" which contains the names of the files which my-first-patch modifies, adds or removes - A file ".patches/my-first-patch.patch", which is the context diff, basically the main output of patcher. - Optionally a file ".patches/my-first-patch.txt" which contains the patch's changelog, description or whatever you put in there. WALKTHROUGHT
Let's start. Go into /usr/src/linux (or wherever). Now let's start with changing some source files: patcher -n my-patch kernel/sched.c OK, patcher copied kernel/sched.c to kernel/sched.c~my-patch for you, the program has also done some magic in the .patches directory, which won't be of interest to us now. Now edit kernel/sched.c a bit. Now we're ready to document the patch: Create .patches/my-patch.txt Now generate a patch: patcher -r This will generate ".patches/my-patch.patch". Take a look at this file. Now we remove our change to sched.c by going backwards: patcher -b Look at where we're now: patcher -s Now let's add another file to my-patch. First we re-apply the patch: patcher -a Now edit a second file: patcher kernel/printk.c Note that here we gave patcher a single argument, without command line options. This always tells patcher to add another file to the cur- rent patch. Edit kernel/printk.c Refresh my-patch: patcher -r Now start a second patch: patcher -n my-second-patch kernel/sched.c Here we have a filename in the command line for patcher, so we edit a file. But now we specified a patch name with -n. This told patcher to create a new patch. Now patcher manages two patches, "my-patch" and "my-second-patch". Edit kernel/sched.c, to make some changes for my-second-patch Generate my-second-patch: patcher -r Take a look in ".patches/my-second-patch.patch". Also note that "my-second-patch.patch" has been added to the series file. Whenever you manually begin a patch, it will automatically be put into the series file. In this way, the whole thing is stackable. If you have four patches applied, say "patch-1", "patch-2", "patch-3" and "patch-4", and if patch-2 and patch-4 both touch kernel/sched.c then you will have: kernel/sched.c~patch-2 Original copy, before patch-2 kernel/sched.c~patch-4 Copy before patch-4. Contains changes from patch-2 kernel/sched.c Current working copy. Contains changes from patch-4. This means that your diff headers contain "~patch-name" in them, which is convenient documentation. To end our tour, we remove both patches: patcher -b patcher -b That's pretty much it, really. SEE ALSO
Andrew Morton's patch scripts at http://www.zip.com.au/~akpm/linux/patches/ I stole the idea from him and even most of this documentation. At http://savannah.nongnu.org/projects/quilt/ you'll find Quilt. That's the successor of Andrew's original scripts. They do the same as patcher (and slightly more), but with tenthousand shell scripts. AUTHOR
Holger Schurig <holgerschurig usingthedomain gmx.de> perl v5.8.4 2004-05-21 PATCHER(1)