2.6.32
这里只对README里面感觉重要的地方进行了翻译，翻译的并不完全。
关于文档
-在Documentation/子目录中有许多的README文件，它们包含了各种信息例如特定内核的驱动安装注意事项。可以查看Documentation/00-INDEX文件，这个文件包含了一个列表，指出了每一个文件包含什么信息。还应该看看Changes文件，这个文件可能包含了你升级内核的时候出现的问题的相关信息。
-Documentation/DocBook子目录为开发者和用户提供了一些指南。这些指南能够用许多种格式提交例如:PostScript(.ps),PDF,HTML,特别值得一提的是Man-pages。安装之后，使用"make psdocs", "make pdfdocs", "make htmldocs"，或者""make mandocs"会生成相应的文档。
安装内核源代码
-如果你要安装整个源代码，那么把源代码的tar包放到一个具有权限的目录里面（例如你的home目录）然后解压：
gzip -cd linux-2.6.XX.tar.gz | tar xvf -
或者
bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf -
这里XX就是版本号，视具体情况而定。
不要使用/usr/src/linux这个地方！这个地方具有一些内核的头文件（不是全部的），这些头文件被库的文件使用。那么应该和库相匹配，
- You can also upgrade between 2.6.xx releases by patching. Patches are
distributed in the traditional gzip and the newer bzip2 format. To
install by patching, get all the newer patch files, enter the
top level directory of the kernel source (linux-2.6.xx) and execute:
gzip -cd ../patch-2.6.xx.gz | patch -p1
or
bzip2 -dc ../patch-2.6.xx.bz2 | patch -p1
(repeat xx for all versions bigger than the version of your current
source tree, _in_order_) and you should be ok. You may want to remove
the backup files (xxx~ or xxx.orig), and make sure that there are no
failed patches (xxx# or xxx.rej). If there are, either you or me has
made a mistake.
Unlike patches for the 2.6.x kernels, patches for the 2.6.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 2.6.x kernel. Please read
Documentation/applying-patches.txt for more information.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- If you are upgrading between releases using the stable series patches
(for example, patch-2.6.xx.y), note that these "dot-releases" are
not incremental and must be applied to the 2.6.xx base tree. For
example, if your base kernel is 2.6.12 and you want to apply the
2.6.12.3 patch, you do not and indeed must not first apply the
2.6.12.1 and 2.6.12.2 patches. Similarly, if you are running kernel
version 2.6.12.2 and want to jump to 2.6.12.3, you must first
reverse the 2.6.12.2 patch (that is, patch -R) _before_ applying
the 2.6.12.3 patch.
You can read more on this in Documentation/applying-patches.txt
- 确保你没有.o文件和一些依赖的文件：
cd linux
make mrproper
现在你可以正确地安装内核的源代码了。
软件需求
编译运行2.6.xx内核需要各种正确版本的软件包。可以查看Document/Changes来确认需要的最早版本号以及如何升级这些软件包。需要注意使用这些软件包的版本如果太旧的华就会导致无法预料的错误，很难对它们进行跟踪，所以不要假设你在编译的时候可以出现很明显的错误然后你只需要升级软件包就可以解决它们。
内核的编译目录：
编译内核的时候，所有的输出文件默认和源代码文件存放在一起。使用"make O=output/dir"(这里是字母O不是数字0)可以指定一个位置来存放输出文件（包括.config）。
例如：
内核源代码目录： /usr/src/linux-2.6.N
编译目录： /home/name/build/kernel
使用下面的命令可以配置和编译内核：
cd /usr/src/linux-2.6.N
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
注意：如果使用了"O=output/dir"选项，那么之后使用make的时候都要指定这个选项。
配置内核：
千万不要跳过这一步，即使你仅仅是升级一个此版本也不要跳过。新的配置选项在每一个release的时候都会被添加进来，如果这些配置文件没有被正确地配置的话会出现奇怪的问题。如果你想要把你已经存在的配置移植到新的版本又不想做太多的工作的话，那么使用"make oldconfig"，这将会仅仅询问你一些新的问题。
-可以选则的各种配置命令有：
"make config" 命令行文本方式的配置接口。
"make menuconfig" 基于命令行文本的具有颜色和单选列表以及对话框的配置接口。
"make xconfig" 基于X Windows(Qt)的配置工具。
"make gconfig" 基于X Windows(Gtk)的配置工具。
"make oldconfig" 默认的所有问题都基于你的已经存在的./.config文件，然后还有一些新的配置标志。
"make silentoldconfig"
和上面类似，不过不会因为一些已经询问国过的问题弄乱屏幕。另外更新了一些依赖。
"make defconfig" 建立一个./.config文件，使用默认的标号的值，这些值或者从arch/$ARCH/defconfig或者从arch/$ARCH/configs/${PLATFORM}_defconfig来获得，这依赖于平台的体系结构。
"make ${PLATFORM}_defconfig"
建立一个./.config文件，使用默认的标号值，这些值来自于arch/$ARCH/configs/${PLATFORM}_defconfig,可以使用"make help"来得到一个你的体系结构中所有可以使用的平台的列表。
"make allyesconfig"
建立一个./.config 文件，把所有的标号值尽可能多地设置为'y'。
"make allmodconfig"
建立一个./.config 文件，把所有的标号值尽可能多地设置为'm'。
"make allnoconfig" 建立一个./.config 文件，把所有的标号值尽可能多地设置为'n'。
"make randconfig" 建立一个./.config 文件，把所有的标号值随机设置。
你可以在Document/kbuild/kconfig.txt找到更多的使用Linux内核配置工具的说明信息。
使用"make config"的一些注意事项：
-一些不需要的驱动会使内核变得更大，并且在一些时候会导致问题：例如寻找一个不存在的控制卡可能会让你的其他的控制卡产生问题。
- 编译内核的时候"Processor type"被设置为比386更高，这会导致内核在386的处理器上面无法工作。
-一个内核如果在编译的时候具有math-emulation(和数学相关的特性)，将会在coprocessor存在的时候仍然使用coprocessor：这时候math emulation将不会被使用到。这样内核会有一点大，但是将会工作在不同的机器上，这些机器可以有math coprocessor也可以没有。
-"kernel hacking"配置细节一般会导致内核更大更慢，甚至会导致内核不稳定，这些通过配置一些函数来主动地打断不好的代码来寻找内核的问题（kmalloc()）。所以，对于一些"development","experimental",或者"debugging"特性的问题，你应该回答'n'.
编译内核：
- 确保你的gcc在3.2版本以上。更多的信息可以查看Documentation/Changes.
要注意你能在这个内核之下运行一个a.out用户程序。
- 使用"make"来创建一个压缩的内核镜像。如果你有lilo的安装和内核的makefile相匹配，也可能运行"make install"，但是你可能首先想要检查你的lilo设置。
做实际的安装，你需要是root用户，但是正常的编译不需要这样。不要什么都用root用户。
- 如果你配置了内核的任何一个部分为"modules"，你就要运行"make modules_install"。
- 内核编译的时候设定详细的输出：
如果你想要在编译的时候看到更多的运行时信息，通过在"make"前面插入"V=1"来实现这个，例如：
make V=1 all
如果想要编译系统提示重新编译每一个目标的原因，那么使用"V=2".默认"V=0"。
- 需要随时保存一个内核的备份以防出现问题。这个很重要。确保你也保存了相应于那个内核的模块的备份。如果你安装一个新的内核，新的内核的版本号和你的工作的内核的版本号是一样的，在"make modules_install"命令之前你需要给你的modules目录做一个备份。
另外，在编译之前你还可以使用"LOCALVERSION"这个内核配置选项来给正规的内核版本后面追加一个唯一的后缀。LOCALVERSION可以在"General Setup"菜单里面被设置。
- 为了启动你的新内核，你需要拷贝内核的镜像(例如编译之后的.../linux/arch/i386/boot/bzImage)拷贝到你正常的启动内核的地方。
- 直接从软盘启动内核而不实用bootloader（例如LILO），已经不再被支持了。
如果你从一个硬盘驱动器启动Linux，你需要改动你的bootloader的配置文件（例如/etc/lilo.conf等）。内核镜像文件经常是/vmlinuz,/boot/vmlinuz,/bzImage或者/boot/bzImage.为了使用新的内核，你需要保存一个旧的内核镜像的副本，然后把新的内核镜像拷贝到相应的位置，然后你可能必须更新载入映射(例如运行LILO)，这样你在能够加载内核。
最后，关闭系统，重新启动。
如果你想要改变默认的启动设备，video mode,ramdisk size等。在内核镜像里面，使用'rdev'程序，不用必须重新编译你的内核来改变这些参数。
- 然后重新启动你就能够使用新的内核了。
IF SOMETHING GOES WRONG:
- If you have problems that seem to be due to kernel bugs, please check
the file MAINTAINERS to see if there is a particular person associated
with the part of the kernel that you are having trouble with. If there
isn't anyone listed there, then the second best thing is to mail
them to me (), and possibly to any other
relevant mailing-list or to the newsgroup.
- In all bug-reports, *please* tell what kernel you are talking about,
how to duplicate the problem, and what your setup is (use your common
sense). If the problem is new, tell me so, and if the problem is
old, please try to tell me when you first noticed it.
- If the bug results in a message like
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your
system log, please duplicate it *exactly*. The dump may look
incomprehensible to you, but it does contain information that may
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/oops-tracing.txt
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
This utility can be downloaded from
.
Alternately you can do the dump lookup by hand:
- In debugging dumps like the above, it helps enormously if you can
look up what the EIP value means. The hex value as such doesn't help
me or anybody else very much: it will depend on your particular
kernel setup. What you should do is take the hex value from the EIP
line (ignore the "0010:"), and look it up in the kernel namelist to
see which kernel function contains the offending address.
To find out the kernel function name, you'll need to find the system
binary associated with the kernel that exhibited the symptom. This is
the file 'linux/vmlinux'. To extract the namelist and match it against
the EIP from the kernel crash, do:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending
order, from which it is simple to find the function that contains the
offending address. Note that the address given by the kernel
debugging messages will not necessarily match exactly with the
function addresses (in fact, that is very unlikely), so you can't
just 'grep' the list: the list will, however, give you the starting
point of each kernel function, so by looking for the function that
has a starting address lower than the one you are searching for but
is followed by a function with a higher address you will find the one
you want. In fact, it may be a good idea to include a bit of
"context" in your problem report, giving a few lines around the
interesting one.
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the REPORTING-BUGS document for details.
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
clean". You'll also need to enable CONFIG_PROC_FS (via "make config").
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
You can now use all the usual gdb commands. The command to look up the
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
with the EIP value.)
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
