[97123] in RedHat Linux List
Re: Kernel Questions (long response about kernels and patches)
daemon@ATHENA.MIT.EDU (William Stearns)
Sun Nov 1 01:33:51 1998
Date: Sun, 1 Nov 1998 01:36:35 -0500 (EST)
From: William Stearns <wstearns@pobox.com>
To: ML-redhat <redhat-list@redhat.com>, Steve Ettorre <sme@nycap.rr.com>
cc: "G. Allen Morris III" <gam3@dharma.sehda.com>
In-Reply-To: <363B9BB8.5879A2D2@nycap.rr.com>
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
Good evening, Steve,
On Sat, 31 Oct 1998, Steve Ettorre wrote:
> I have some basic questions about the linux kernel and making changes to
> it.
>
> * First, I have RH v5.1 with kernel 2.0.35. I notice that all the RH
> kernels seem to be 2.0.x. Yet at ftp sites like sunsite and others,
> there are many 2.1.x kernels that can be downloaded. I have been
> led to belive that the 2.1.x kernels contain more advanced features
> than 2.0.x versions (e.g. more recent drivers). What is the
> difference between these two kernel versions?
The numbering scheme for the kernels dictates that anything with
and even second number (the "0" in 2.0.35 or the "2" in 1.2.13) is a
stable kernel; one suited to production use. Any kernels with an odd
second digit, such as 2.1.126, are development kernels. The stable
kernels are generally more stable and have fewer features, the development
kernels have more features (including things like improved speed or better
use of memory), but because the developers need to be able to rip code
apart occasionally to rewrite or reimplement it, development kernel
components aren't guaranteed to work. For example, I'm writing this on a
laptop with a prerelease of kernel 2.1.127. Because support for more than
16 scsi disks was added recently, I'm fighting the pcmcia scsi code to get
it to work. The guidelines are these:
- Use stable kernels on machines that can't afford downtime.
- Feel free to try out development kernels on machines that can
afford downtime, or on which the stable kernels won't run at all.
- If a particular feature breaks in a development kernel, decide
whether A) you want to help fix it, B) you can't help fix it right now,
but can live without it, or C) you absolutely need it, which implies you
back down to an earlier stable or development kernel that has that feature
working.
The kernel developers have been adding a _bunch_ of new features
and hardware support in 2.1 over the last two years. The 2.1 kernel has
entered a "code freeze" - no major new features will be added to it. For
the last few months, the developers have been focusing solely on cleaning
up the remaining problems in the 2.1 series. Once a general consensus is
reached that these problems have been fixed, the most newest 2.1 kernel
will become 2.2.0, starting a new stable kernel series. According to a
recent interview with Linus Torvalds, this should happen within a month or
two.
Because we're in a code freeze, the general rule is that the code
only gets more stable. The occasional glitches like the scsi problem
mentioned above will get rarer and rarer. For this reason, this is
actually a great time to try out the new kernels. There are some features
in them that make them a good deal faster than the 2.0 kernels.
> * I understand that certain advanced features can be downloaded as
> patch files which can be included in my existing kernel. My view is
> that these patches become permanent additions to the kernel.
> Alternatively, I believe that kernel modules can be downloaded
> which are then automatically loaded by the kernel only when needed.
You've got the right idea. The kernel proper is always loaded
into memory, whether it's in use or not. Modules are sections of
executable kernel code that are not always loaded into memory. By loading
modules only when they're needed and unloading them when they're not, that
memory is freed up for other programs or caching. For example, my laptop
has floppy support as a module. When I'm not using the floppy drive, I
have 46K more memory for my programs.
(The other advantage for developers is that they can try out a
driver (like the floppy driver) on a new piece of equipment, remove the
module, make changes to the code, recompile just the new code, reload the
module, and try the new module without having to reboot the computer to
load an entirely new kernel.)
As for patches, let me try an example. Lets say someone opened up
the source for 2.1.126, compiled a new kernel from it, and found that sd.c
(the code that deals with scsi disks) didn't compile at all. They took a
look at the code and said, "Aha!" (you have to say Aha!... :-). "The
changes to support >16 disks was not finished. If I change these three
lines, it'll work!". A few cups of coffee and a compile later, sure
enough, it does work.
The problem is that the person that made the changes doesn't want
to send an email to the other developers with an english description of
what he did; especially if the change covered hundreds of lines of code.
To solve this, there is a standard format (actually, 3 or 4 standard
formats) for describing the difference between two versions of a file (the
original non-working version and the changed working version).
This person puts the original file and the changed file in the
same directory under slightly different names (file.orig and file are
common - the files can also be in different directories with the same
name). Then he or she runs:
diff -u linux/drivers/scsi/sd.c.orig linux/drivers/scsi/sd.c
The diff program outputs a file (called a patch) that describes
the "diff"erence between the two versions. This programmer (G. Allen
Morris III, in this real-life example - I hope you don't mind my using
your message as an example!) then places the patch in an email message and
sends it off to the kernel developers on the linux-kernel mailing list.
------------------------------------------------------------------------
To: Linus Torvalds <torvalds@*removed*for*privacy*.com>
Cc: Kernel Mailing List <linux-kernel@vger.rutgers.edu>
Subject: Re: Linux-2.1.126...
Date: Sat, 24 Oct 1998 01:00:34 -0700
From: "G. Allen Morris III" <gam3@dharma.sehda.com>
I did not get them all on my first try.
There is also a `bug' in linux/drivers/scsi/sd.c. Here is what I
think that it sould be. THIS IS ONLY A GUESS!!!!
--- linux/drivers/scsi/sd.c.orig Sat Oct 24 00:16:04 1998
+++ linux/drivers/scsi/sd.c Sat Oct 24 00:52:04 1998
@@ -1783,13 +1783,13 @@
for (sdgd = gendisk_head; sdgd; sdgd = sdgd->next)
{
- if (sdgd->next >= sd_gendisks && sdgd->next <= LAST_SD_GENDISK)
+ if (sdgd->next >= sd_gendisks && sdgd->next <= &LAST_SD_GENDISK)
removed++, sdgd->next = sdgd->next->next;
else sdgd = sdgd->next;
}
- if (removed != N_USED_SCSI_DISKS)
+ if (removed != N_USED_SD_MAJORS)
printk("%s %d sd_gendisks in disk chain",
- removed > N_USED_SCSI_DISKS ? "total" : "just", removed);
+ removed > N_USED_SD_MAJORS ? "total" : "just", removed);
}
---------------------------------
G. Allen Morris III
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------
This particular patch format starts at the "--- linux/drivers/..."
line. Any lines with a "-" as the first character get removed from the
original version. Any lines with a "+" get added. Lines with neither as
the first character are simply placed there to show context. Once all the
+'s and -'s get processed, you're left with the new version.
When I read the list, I see that this would be useful to me. I
save the message as a file, go to the directory above the the 2.1.126
kernel tree, and type:
patch -s --ignore-whitespace --remove-empty-files -p0 </path/to/the/email/message
The "patch" program ignores the english text in the message and
uses the patch section to change the non-working version of sd.c into the
working version.
Patches can be simple ones like the above that simply make a small
change. Patches can be much larger, though, including a patch that adds a
major new feature like a device filesystem called "devfs" [*1], or even
the changes between the kernel versions. When Linux puts a new kernel in
ftp.kernel.org/pub/linux/kernel/2.1, he not only puts linux-2.1.126.tar.gz
(~10M) there, he also puts patch-2.1.126.gz there (~300K). If I already
have the source tree for 2.1.125, I only need to download the patch and
apply it to the 2.1.125 tree (while my example above showed how to create
a patch for a single file, "diff" and "patch" can work on multiple files
or entire directory trees as well).
Note that a patch describes the difference between two versions of
a file. It should be obvious that to get the new version, you not only
need the patch but also the old version.
There are a number of other facets to patching - see "man patch"
and "man diff" for more details.
Back to your original questions!
> Is my understanding correct? How do I recognize a patch from a
> module file (is there a naming convention?)? When I download a
> module file, how can I install it such that I can make use of it
> using kerneld?
A patch file will commonly look like the code in my example
message. The filename _may_ end in .patch or -patch, but it's by no means
required. If there is no surrounding English text, using the file command
on a patch file will return "'diff' output text".
Module filenames commonly end in ".o". You'll have a number of
modules under /lib/modules/2.0.35/ . If you run the 'file' command on
them, you'll see:
file /lib/modules/2.0.35/net/dummy.o<Enter>
dummy.o: ELF 32-bit LSB relocatable, Intel 80386, version 1, not stripped
, which means it's executable code.
To make use of a module file for your particular kernel, download
it to /lib/modules/2.0.35/misc/ and then try:
modprobe my_new_module_name.o<Enter>
One closing thought. If you, or anyone else reading this, would
like to try compiling a new kernel, pull down a copy of the Buildkernel
program from http://www.pobox.com/~wstearns/buildkernel/ . It's in rpm
format. The easiest way to start is to run:
buildkernel --NEWESTBETA<Enter>
, which will build the newest beta (development) kernel for you (to
build a new custom _stable_ kernel, use "buildkernel --NEWESTSTABLE").
Buildkernel makes patching kernels much easier - see the documentation
under /usr/doc/buildkernel... for more details.
If you have any more questions about any of this, including
Buildkernel, feel free to contact me. Either way, let me know how your
exploration goes...
Cheers,
- Bill
*1 80K, at ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/
Resources:
- The kernel-howto at http://sunsite.unc.edu/linux/HOWTO/ tells how to
build a kernel.
- Buildkernel, at http://www.pobox.com/~wstearns/buildkernel/ actually
builds custom kernels for you, including automatic patching.
- The linux-kernel mailing list FAQ at: http://www.tux.org/lkml/
- The actual linux-kernel mailing list. The list is primarily for
developers - you're better off posting questions not directly related to
kernel development to mailing lists like this one. If you decide you'd
like to do some kernel development, by all means: to subscibe, send the
line "subscribe linux-kernel" in the body of a message to
majordomo@vger.rutgers.edu . If you'd just like to see the archives of
the list, head to http://www.linuxhq.com/
---------------------------------------------------------------------------
Unix _is_ user friendly. It's just very selective about who its friends
are. And sometimes even best friends have fights.
William Stearns (wstearns@pobox.com)
Mason, buildkernel, and named2hosts are at: http://www.pobox.com/~wstearns
---------------------------------------------------------------------------
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.
