linux编译注解

By admin in 澳门新葡亰官网app on 2019年9月3日

[RK_2014_0919]Linux Kernel Hacking,hacking

Guide to building the Linux kernel.

This is forked from , and the csi
tool is added to the atheros driver.

        Linux kernel release 3.x <;

Where do I find the kernel?

The latest source code for the Linux kernel is kept on kernel.org. You
can either download the full source code as a tar ball (not recommended
and will take forever to download), or you can check out the code from
the read-only git repositories.


These are the release notes for Linux version 3.  Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong.

What tools do I need?

To build the Linux kernel from source, you need several tools: git,
make, gcc, and (optionally) ctags and/or ncurses-dev. The tool packages
may be called something else in your Linux distribution, so you may need
to search for the package. The ncurses-dev tools are used if you “make
menuconfig” or “make nconfig”.

On Ubuntu, you can get these tools by running:

sudo apt-get install libncurses5-dev gcc make git exuberant-ctags

On Red Hat based systems like Fedora, Scientific Linux, and CentOS you
can run:

sudo yum install gcc make git ctags ncurses-devel

Linux kernel release 3.x <;

WHAT IS LINUX?

Which kernel to build?

If you want to test to see if a bug is fixed then test against the
latest stable kernel from kernel.org. If you are brave and your system
is backed up the latest release candidate from Linus’s tree is a great
target. Sometimes the maintainer may want you to use an experimental
branch from their own git tree. You should use the git URL they gave you
instead of the git URLs below.

If you’re doing development for a new feature, or trying to test a bug
fix, you should use Linus’ tree, or the subsystem maintainer’s -next
tree. Most subsystem maintainers keep their git trees on kernel.org.
When in doubt, use Linus’ tree.

If you don’t understand what a stable or release candidate kernel is,
you should read the KernelDevProcess page.

These are the release notes for Linux version 3. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong.

  Linux is a clone of the operating system Unix, written from scratch
by
  Linus Torvalds with assistance from a loosely-knit team of hackers
across
  the Net. It aims towards POSIX and Single UNIX Specification
compliance.

Downloading the latest stable tree

First, checkout the stable kernel git repository:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable

Next, find the latest stable kernel tag by running

git tag -l | less

Find the latest stable kernel by looking for the largest vX.Y.Z values.
For example, use the v3.1 tag over the v3.0.46 tag. If v3.1.1 is
available, use that instead of v3.1. The kernel tags that end with -rcX
are release candidate kernels, not stable kernels.

Now checkout the code associated with that kernel with the command

git checkout -b stable tag

Where tag is the latest vX.Y.Z tag you found.

WHAT IS LINUX?

  It has all the features you would expect in a modern fully-fledged
Unix,
  including true multitasking, virtual memory, shared libraries,
demand
  loading, shared copy-on-write executables, proper memory management,
  and multistack networking including IPv4 and IPv6.

Downloading the latest -rc tree

Check out Linus’ tree:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux

Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers
across
the Net. It aims towards POSIX and Single UNIX Specification compliance.

  It is distributed under the GNU General Public License – see the
  accompanying COPYING file for more details.

Setting up your kernel configuration

Many kernel drivers can be turned on or off, or built as modules. The
.config file in the kernel source directory determines which drivers are
built. When you download the source tree, it doesn’t come with a .config
file. You have several options on generating a .config file. The easiest
is to duplicate your current config.

It has all the features you would expect in a modern fully-fledged
Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.

ON WHAT HARDWARE DOES IT RUN?

Duplicating your current config

If you’re trying to see if a bug is fixed, you probably want to
duplicate the configuration on your running kernel. That config file is
stored somewhere in /boot/. There might be several files that start with
config, so you want the one associated with your running kernel. You can
find that by running uname -a and finding the config file that ends
with your kernel version number. Copy that file into the source
directory as .config. Or just run this command:

cp /boot/config-`uname -r`* .config

It is distributed under the GNU General Public License – see the
accompanying COPYING file for more details.

  Although originally developed first for 32-bit x86-based PCs (386 or
higher),
  today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC
and
  UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH,
Cell,
  IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS
CRIS,
  Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.

Making the default config

Remember, a default config may not have the options you are currently
using. Run

make defconfig

ON WHAT HARDWARE DOES IT RUN?

  Linux is easily portable to most general-purpose 32- or 64-bit
architectures
  as long as they have a paged memory management unit (PMMU) and a port
of the
  GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux
has
  also been ported to a number of architectures without a PMMU,
although
  functionality is then obviously somewhat limited.
  Linux has also been ported to itself. You can now run the kernel as
a
  userspace application – this is called UserMode Linux (UML).

Making a minimal config

Compiling a kernel from scratch from a distribution configuration can
take “forever” because the distros turn on every hardware configuration
possible. For people wanting to do kernel development fast, you want to
make a minimal configuration. Steve Rostedt uses ktest.pl
make_min_config to get a truely minimum config, but it will take a day
or two to build. Warning: make sure you have all your USB devices
plugged into the system, or you won’t get the drivers for them!

Although originally developed first for 32-bit x86-based PCs (386 or
higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC
and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH,
Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS
CRIS,
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.

DOCUMENTATION:

Changing your config

If you need to make any changes to your configuration, you can run one
of the following commands. These require the curses tools to be
installed.

make menuconfig

or

make nconfig

Linux is easily portable to most general-purpose 32- or 64-bit
architectures
as long as they have a paged memory management unit (PMMU) and a port of
the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux
has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application – this is called UserMode Linux (UML).

 – There is a lot of documentation available both in electronic form
on
   the Internet and in books, both Linux-specific and pertaining to
   general UNIX questions.  I’d recommend looking into the
documentation
   subdirectories on any Linux FTP site for the LDP (Linux
Documentation
   Project) books.  This README is not meant to be documentation on
the
   system: there are much better sources available.

Building the kernel

Run

make

Or, if you have a multi-core processor, run

make -jX

Where X is a number like 2 or 4. If you have a dual core, 2 or 3 might
be good. Quad core, 4 or 6. Do not run with really big numbers unless
you want your machine to be dog-slow!

Walk away, get some coffee, lunch, or go read some comics.

DOCUMENTATION:

 – There are various README files in the Documentation/ subdirectory:
   these typically contain kernel-specific installation notes for some
   drivers for example. See Documentation/00-INDEX for a list of what
   is contained in each file.  Please read the Changes file, as it
   contains information about the problems, which may result by
upgrading
   your kernel.

Installing the kernel

To install a kernel, you will need to either manually update your GRUB
configuration file, or have an installkernel script. This script
installs the kernel to /boot/, installs modules to /lib/modules/X.Y.Z/
(where X.Y.Z is something like 3.1.5), and updates file
/boot/grub/grub.conf. Fortunately, Ubuntu provides an installkernel
script in /sbin/installkernel. The grubby RPM provides it for RPM based
systems.

If you have an installkernel script, you can just run

sudo make modules_install install

Or if you don’t have sudo installed, run

su -c "make modules_install install"

– There is a lot of documentation available both in electronic form
on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I’d recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.

 – The Documentation/DocBook/ subdirectory contains several guides for
   kernel developers and users.  These guides can be rendered in a
   number of formats:  PostScript (.ps), PDF, HTML, & man-pages, among
others.
   After installation, “make psdocs”, “make pdfdocs”, “make htmldocs”,
   or “make mandocs” will render the documentation in the requested
format.

Running your kernel

First, make sure you know how to select a kernel at boot time. If your
new kernel is broken, you want a way to boot into your old kernel. The
grub bootloader usually presents users with a choice of kernels and you
can reboot into a known good kernel if your new compile doesn’t work.
Some distros use a default grub config that hides that menu. You can
usually get the menu to appear by mashing the ESC key during boot after
the BIOS display disappears.

Ubuntu: To make the grub menu always appear on boot under Ubuntu, remove
the GRUB_HIDDEN_TIMEOUT_QUIET line from /etc/default/grub. You may
want to increase the GRUB_DEFAULT timeout from 0 to 15 seconds or more.
After you’ve finished editing the grub file you may need to update your
grub file.

sudo update-grub2

You will (usually) need to reboot into your new kernel.

– There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
is contained in each file. Please read the Changes file, as it
contains information about the problems, which may result by upgrading
your kernel.

INSTALLING the kernel source:

Patching your kernel

There are several ways to apply a patch to your kernel. Usually the
maintainer will send you a patch as attachment, or inline in the mail.
You should either save the file, or copy and paste the patch into a new
file.

To apply the patch, go to the base kernel directory and run

git am patchfile

Where patchfile is the file you saved. If patch fails, you can run:

git am --abort
git reset --hard HEAD
git am -3 patchfile

This applies the patch, and attempts to run a three-way merge if the
patch application fails. If all else fails, you can attempt to duplicate
the patch changes by hand.

Then you need to re-build your kernel and reboot.

(Note: the older way of manually patching the kernel
with patch -p1 <patchfile does not create any git history, which makes
it hard to revert and retry different patches. You will often have to go
through several patches with a maintainer to find the right fix for a
bug, so having the git history is useful.)

– The Documentation/DocBook/ subdirectory contains several guides for
kernel developers and users. These guides can be rendered in a
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among
others.
After installation, “make psdocs”, “make pdfdocs”, “make htmldocs”,
or “make mandocs” will render the documentation in the requested format.

 – If you install the full sources, put the kernel tarball in a
   directory where you have permissions (eg. your home directory) and
   unpack it:

Reverting a patch

If a maintainer wants you to revert a patch you have applied, and try a
different patch, you can use git to reset the history to the point
before the patch was applied.

If git log shows the patch to be removed is the first log entry, you
can run

git reset --hard HEAD^

If you need to revert several patches, you can use git log to find the
commit ID of the first commit before those patches. For instance, say
you have applied two patches to the stable tree 3.4.17, and you want to
revert those patches. git log will look like this:

$ git log --pretty=oneline --abbrev-commit
8901234 Testing patch 2
1234567 Testing patch 1
5390967 Linux 3.4.17
1f94bd4 drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13
0187c24 x86, mm: Use memblock memory loop instead of e820_RAM
a0419ca staging: comedi: amplc_pc236: fix invalid register access during detach

To reset your tree to 3.4.17, you can run:

git reset --hard 5390967

If you look at the commits with gitk you will notice that the 3.4.17
commit is also tagged as v3.4.17. You can reset by tag as well:

git reset --hard v3.4.17

INSTALLING the kernel source:

     gzip -cd linux-3.X.tar.gz | tar xvf –

Tips and Tricks

If you have a driver installed as a module, you can recompile just that
driver. This saves time, because the kernel build system doesn’t have to
look for changes across the entire kernel tree or compile any of the
built-in code.

All module files end with .ko. The kernel make system will compile just
one .ko file if you give it the full path to the file:

make drivers/usb/host/xhci-hcd.ko

Note you will need to be in the base kernel source directory for this to
work. You can’t make from a different directory.

You can also reload drivers without rebooting your kernel. For example,
I can remove the xHCI driver and reload it with

sudo rmmod xhci-hcd && sudo insmod drivers/usb/host/xhci-hcd.ko

Make sure that you understand the consequences of unloading your driver!
For instance, if you unload the USB core driver in order to try out
changes, your USB mouse and keyboard aren’t going to work until the USB
core driver is reloaded.

You may have to unload other drivers that depend on your driver before
you can reload it. Use lsmod to find which drivers that are loaded
depend on your driver. E.g.

$ lsmod | grep usb
usbnet                 26596  2 rndis_host,cdc_ether
mii                     5198  1 usbnet
btusb                  16575  0 
usbhid                 44621  1 hid_logitech
usbcore               191078  9 xhci_hcd,rndis_host,cdc_ether,usbnet,btusb,uvcvideo,usbhid,ehci_hcd
usb_common              1093  1 usbcore

In this case, usbcore is used by xhci_hcd, rndis_host, cdc_ether,
usbnet, btusb, uvcvideo, usbhid, and ehci_hcd. I would have to unload
all those drivers in order to reload the usbcore module.

二、网址

 

                       

– If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:

   or

linux内核配置什是必须的

内核配置注意事项

如果打算自己编译内核的话(内核源代码可以到ftp://ftp.kernel.org/pub/kernel/
下载,国内下载可以到ftp://ftp.cn.kernel.org/pub/kernel/
这样下载速度更快),在编译之前一般都要先用make menuconfig或make
xconfig配置内核。我的系统中没有xconfig,所以只能用menuconfig。在我的Compaq
Presario V3414TX laptop上编译2.6.23.x内核时,以下选项是必须要注意的:

1、Networking –>

Wireless LAN –>

[M]Generic IEEE 802.11 Networking Stack (mac80211)

这是Linux当前使用的网络栈模块。如果想要使用无线网卡(我的是Intel
PRO/3945
ABG),就要将此选项编为模块(或者编入内核也可以,那样启动时就会自动加载mac80211模块)。否则到时候就要自己去intellinuxwireless.org下载该模块进行安装。

2、Device Drivers –>

Network Drivers –>

Wireless LAN–>

[M]Intel PRO/Wireless 3945ABG Network Connection

Intel PRO/Wireless 3945ABG Network
Connection这一项可以换成你的任何无线网卡。同样,如果你想使用无线网卡的话,这一项也是要编为模块的。但是我最后编译的2.6.23.14内核中没有这一项,因此就必须到intellinuxwireless.org下载3495ABG的驱动了。

3、File System –>

DOS/FAT/NT Filesystems –>

<*> VFAT (Windows-95) fs support

(437) Default codepage for FAT (NEW)

(utf8) Default iocharset for FAT (NEW)

将 VFAT (Windows-95) fs support
选为y是为了让内核能支持FAT格式硬盘的挂载。这里codepage要用437;在网上很多文章都说要用936,这样才能让FAT硬盘的文件名显示支持中文,但事实上我这么做之后,在挂载FAT分区时却被新内核提示无法挂载,系统日志显示找不到codepage
936——可是我已经将codepage
936编进内核了啊(下文会说明),因此在这一点上我相当困惑。后来发现FAT分区的中文文件名能否正确显示是取决于
Default iocharset for FAT
这一项,其字符编码要使用utf8才行。原因上,也许是因为Windows的FAT分区默认的字符编码是ascii或gb2312,而Linux默认的是utf8编码,认不得gb2312……这个地方我也不太明白。

4、File System –>

Native Language Support –>

[M]Simplified Chinese charset (CP936, GB2312)

想要中文支持的话,当然要选上这一项(……余下全文>>
 

gzip -cd linux-3.X.tar.gz | tar xvf –

     bzip2 -dc linux-3.X.tar.bz2 | tar xvf –

怎编译linux内核

内核,是一个操作系统的核心。它负责管理系统的进程、内存、设备驱动程序、文件和网络系统,决定着系统的性能和稳定性。Linux作为一个自由软件,
在广大爱好者的支持下,内核版本不断更新。新的内核修订了旧内核的bug,并增加了许多新的特性。如果用户想要使用这些新特性,或想根据自己的系统度身定
制一个更高效,更稳定的内核,就需要重新编译内核。本文将以RedHat Linux
6.0(kernel
2.2.5)为操作系统平台,介绍在Linux上进行内核编译的方法。

  一、 下载新内核的源代码

  目前,在Internet上提供Linux源代码的站点有很多,读者可以选择一个速度较快的站点下载。笔者是从站点www.kernelnotes.org上下载了Linux的最新开发版内核2.3.14的源代码,全部代码被压缩到一个名叫Linux-2.3.14.tar.gz的文件中。

  二、 释放内核源代码

  由于源代码放在一个压缩文件中,因此在配置内核之前,要先将源代码释放到指定的目录下。首先以root帐号登录,然后进入/usr/src子目录。如果用户在安装Linux时,安装了内核的源代码,则会发现一个linux-2.2.5的子目录。该目录下存放着内核2.2.5的源代码。此外,还会发现一个指向该目录的链接linux。删除该连接,然后将新内核的源文件拷贝到/usr/src目录中。

  (一)、用tar命令释放内核源代码

  # cd /usr/src

  # tar zxvf Linux-2.3.14.tar.gz

  文件释放成功后,在/usr/src目录下会生成一个linux子目录。其中包含了内核2.3.14的全部源代码。

  (二)、将/usr/include/asm、/usr/inlude/linux、/usr/include/scsi链接到/usr/src/linux/include目录下的对应目录中。

  # cd /usr/include

  # rm -Rf asm linux

  # ln -s /usr/src/linux/include/asm-i386 asm

  # ln -s /usr/src/linux/include/linux linux

  # ln -s /usr/src/linux/include/scsi scsi

  (三)、删除源代码目录中残留的.o文件和其它从属文件。

  # cd /usr/src/linux

  # make mrproper

  三、 配置内核

  (一)、启动内核配置程序。

  # cd /usr/src/linux

  # make config

  除了上面的命令,用户还可以使用make
menuconfig命令启动一个菜单模式的配置界面。如果用户安装了X
window系统,还可以执……余下全文>>
 

Kernel Hacking,hacking
KernelBuild Guide to building the Linux kernel. Where do I find the
kernel? The latest source code for the Linux kernel is kept
onkerne…

or

   Replace “X” with the version number of the latest kernel.

bzip2 -dc linux-3.X.tar.bz2 | tar xvf –

   Do NOT use the /usr/src/linux area! This area has a (usually
   incomplete) set of kernel headers that are used by the library
header
   files.  They should match the library, and not get messed up by
   whatever the kernel-du-jour happens to be.

Replace “X” with the version number of the latest kernel.

 – You can also upgrade between 3.x 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-3.X) and execute:

Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.

     gzip -cd ../patch-3.x.gz | patch -p1

– You can also upgrade between 3.x 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-3.X) and execute:

   or

gzip -cd ../patch-3.x.gz | patch -p1

     bzip2 -dc ../patch-3.x.bz2 | patch -p1

or

   Replace “x” for all versions bigger than the version “X” of your
current
   source tree, _in_order_, and you should be ok.  You may want to
remove
   the backup files (some-file-name~ or some-file-name.orig), and make
sure
   that there are no failed patches (some-file-name# or
some-file-name.rej).
   If there are, either you or I have made a mistake.

bzip2 -dc ../patch-3.x.bz2 | patch -p1

   Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
   (also known as the -stable kernels) are not incremental but instead
apply
   directly to the base 3.x kernel.  For example, if your base kernel is
3.0
   and you want to apply the 3.0.3 patch, you must not first apply the
3.0.1
   and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2
and
   want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that
is,
   patch -R) _before_ applying the 3.0.3 patch. You can read more on
this in
   Documentation/applying-patches.txt

Replace “x” for all versions bigger than the version “X” of your
current
source tree, _in_order_, and you should be ok. You may want to
remove
the backup files (some-file-name~ or some-file-name.orig), and make
sure
that there are no failed patches (some-file-name# or
some-file-name.rej).
If there are, either you or I have made a mistake.

   Alternatively, the script patch-kernel can be used to automate this
   process.  It determines the current kernel version and applies any
   patches found.

Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead
apply
directly to the base 3.x kernel. For example, if your base kernel is
3.0
and you want to apply the 3.0.3 patch, you must not first apply the
3.0.1
and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2
and
want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that
is,
patch -R) _before_ applying the 3.0.3 patch. You can read more on this
in
Documentation/applying-patches.txt

     linux/scripts/patch-kernel linux

Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.

   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.

linux/scripts/patch-kernel linux

 – Make sure you have no stale .o files and dependencies lying around:

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.

     cd linux
     make mrproper

– Make sure you have no stale .o files and dependencies lying around:

   You should now have the sources correctly installed.

cd linux
make mrproper

SOFTWARE REQUIREMENTS

You should now have the sources correctly installed.

   Compiling and running the 3.x kernels requires up-to-date
   versions of various software packages.  Consult
   Documentation/Changes for the minimum version numbers required
   and how to get updates for these packages.  Beware that using
   excessively old versions of these packages can cause indirect
   errors that are very difficult to track down, so don’t assume that
   you can just update packages when obvious problems arise during
   build or operation.

SOFTWARE REQUIREMENTS

BUILD directory for the kernel:

Compiling and running the 3.x kernels requires up-to-date
versions of various software packages. Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don’t assume that
you can just update packages when obvious problems arise during
build or operation.

   When compiling the kernel, all output files will per default be
   stored together with the kernel source code.
   Using the option “make O=output/dir” allow you to specify an
alternate
   place for the output files (including .config).
   Example:

BUILD directory for the kernel:

     kernel source code: /usr/src/linux-3.X
     build directory:    /home/name/build/kernel

When compiling the kernel, all output files will per default be
stored together with the kernel source code.
Using the option “make O=output/dir” allow you to specify an alternate
place for the output files (including .config).
Example:

   To configure and build the kernel, use:

kernel source code: /usr/src/linux-3.X
build directory: /home/name/build/kernel

     cd /usr/src/linux-3.X
     make O=/home/name/build/kernel menuconfig
     make O=/home/name/build/kernel
     sudo make O=/home/name/build/kernel modules_install install

To configure and build the kernel, use:

   Please note: If the ‘O=output/dir’ option is used, then it must be
   used for all invocations of make.

cd /usr/src/linux-3.X
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install

CONFIGURING the kernel:

Please note: If the ‘O=output/dir’ option is used, then it must be
used for all invocations of make.

   Do not skip this step even if you are only upgrading one minor
   version.  New configuration options are added in each release, and
   odd problems will turn up if the configuration files are not set up
   as expected.  If you want to carry your existing configuration to a
   new version with minimal work, use “make oldconfig”, which will
   only ask you for the answers to new questions.

CONFIGURING the kernel:

 – Alternative configuration commands are:

Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use “make oldconfig”, which will
only ask you for the answers to new questions.

     “make config”      Plain text interface.

– Alternative configuration commands are:

     “make menuconfig”  Text based color menus, radiolists & dialogs.

“make config” Plain text interface.

     “make nconfig”     Enhanced text based color menus.

“make menuconfig” Text based color menus, radiolists & dialogs.

     “make xconfig”     X windows (Qt) based configuration tool.

“make nconfig” Enhanced text based color menus.

     “make gconfig”     X windows (Gtk) based configuration tool.

“make xconfig” X windows (Qt) based configuration tool.

     “make oldconfig”   Default all questions based on the contents of
                        your existing ./.config file and asking about
                        new config symbols.

“make gconfig” X windows (Gtk) based configuration tool.

     “make silentoldconfig”
                        Like above, but avoids cluttering the screen
                        with questions already answered.
                        Additionally updates the dependencies.

“make oldconfig” Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.

     “make defconfig”   Create a ./.config file by using the default
                        symbol values from either arch/$ARCH/defconfig
                        or arch/$ARCH/configs/${PLATFORM}_defconfig,
                        depending on the architecture.

“make silentoldconfig”
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.

     “make ${PLATFORM}_defconfig”
                        Create a ./.config file by using the default
                        symbol values from
                        arch/$ARCH/configs/${PLATFORM}_defconfig.
                        Use “make help” to get a list of all available
                        platforms of your architecture.

“make olddefconfig”
Like above, but sets new symbols to their default
values without prompting.

     “make allyesconfig”
                        Create a ./.config file by setting symbol
                        values to ‘y’ as much as possible.

“make defconfig” Create a ./.config file by using the default
symbol values from either arch/$ARCH/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.

     “make allmodconfig”
                        Create a ./.config file by setting symbol
                        values to ‘m’ as much as possible.

“make ${PLATFORM}_defconfig”
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use “make help” to get a list of all available
platforms of your architecture.

     “make allnoconfig” Create a ./.config file by setting symbol
                        values to ‘n’ as much as possible.

“make allyesconfig”
Create a ./.config file by setting symbol
values to ‘y’ as much as possible.

     “make randconfig”  Create a ./.config file by setting symbol
                        values to random values.

“make allmodconfig”
Create a ./.config file by setting symbol
values to ‘m’ as much as possible.

   You can find more information on using the Linux kernel config
tools
   in Documentation/kbuild/kconfig.txt.

“make allnoconfig” Create a ./.config file by setting symbol
values to ‘n’ as much as possible.

 – NOTES on “make config”:

“make randconfig” Create a ./.config file by setting symbol
values to random values.

    – Having unnecessary drivers will make the kernel bigger, and can
      under some circumstances lead to problems: probing for a
      nonexistent controller card may confuse your other controllers

“make localmodconfig” Create a config based on current config and
loaded modules (lsmod). Disables any module
option that is not needed for the loaded modules.

    – Compiling the kernel with “Processor type” set higher than 386
      will result in a kernel that does NOT work on a 386.  The
      kernel will detect this on bootup, and give up.

To create a localmodconfig for another machine,
store the lsmod of that machine into a file
and pass it in as a LSMOD parameter.

    – A kernel with math-emulation compiled in will still use the
      coprocessor if one is present: the math emulation will just
      never get used in that case.  The kernel will be slightly
larger,
      but will work on different machines regardless of whether they
      have a math coprocessor or not.

target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp

    – The “kernel hacking” configuration details usually result in a
      bigger or slower kernel (or both), and can even make the kernel
      less stable by configuring some routines to actively try to
      break bad code to find kernel problems (kmalloc()).  Thus you
      should probably answer ‘n’ to the questions for “development”,
      “experimental”, or “debugging” features.

host$ make LSMOD=/tmp/mylsmod localmodconfig

COMPILING the kernel:

The above also works when cross compiling.

 – Make sure you have at least gcc 3.2 available.
   For more information, refer to Documentation/Changes.

“make localyesconfig” Similar to localmodconfig, except it will
convert
all module options to built in (=y) options.

   Please note that you can still run a.out user programs with this
kernel.

You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.

 – Do a “make” to create a compressed kernel image. It is also
   possible to do “make install” if you have lilo installed to suit
the
   kernel makefiles, but you may want to check your particular lilo
setup first.

– NOTES on “make config”:

   To do the actual install, you have to be root, but none of the
normal
   build should require that. Don’t take the name of root in vain.

– Having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers

 – If you configured any of the parts of the kernel as `modules’, you
   will also have to do “make modules_install”.

– Compiling the kernel with “Processor type” set higher than 386
will result in a kernel that does NOT work on a 386. The
kernel will detect this on bootup, and give up.

 – Verbose kernel compile/build output:

– A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.

   Normally, the kernel build system runs in a fairly quiet mode (but
not
   totally silent).  However, sometimes you or other kernel developers
need
   to see compile, link, or other commands exactly as they are
executed.
   For this, use “verbose” build mode.  This is done by inserting
   “V=1” in the “make” command.  E.g.:

– The “kernel hacking” configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer ‘n’ to the questions for “development”,
“experimental”, or “debugging” features.

     make V=1 all

COMPILING the kernel:

   To have the build system also tell the reason for the rebuild of
each
   target, use “V=2”.  The default is “V=0”.

– Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.

 – Keep a backup kernel handy in case something goes wrong.  This is
   especially true for the development releases, since each new
release
   contains new code which has not been debugged.  Make sure you keep
a
   backup of the modules corresponding to that kernel, as well.  If
you
   are installing a new kernel with the same version number as your
   working kernel, make a backup of your modules directory before you
   do a “make modules_install”.

Please note that you can still run a.out user programs with this kernel.

   Alternatively, before compiling, use the kernel config option
   “LOCALVERSION” to append a unique suffix to the regular kernel
version.
   LOCALVERSION can be set in the “General Setup” menu.

– Do a “make” to create a compressed kernel image. It is also
possible to do “make install” if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup
first.

 – In order to boot your new kernel, you’ll need to copy the kernel
   image (e.g. …/linux/arch/i386/boot/bzImage after compilation)
   to the place where your regular bootable kernel is found.

To do the actual install, you have to be root, but none of the normal
build should require that. Don’t take the name of root in vain.

 – Booting a kernel directly from a floppy without the assistance of a
   bootloader such as LILO, is no longer supported.

– If you configured any of the parts of the kernel as `modules’, ing
system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers
across
the Net. It aims towards POSIX and Single UNIyou
will also have to do “make modules_install”.

   If you boot Linux from the hard drive, chances are you use LILO,
which
   uses the kernel image as specified in the file /etc/lilo.conf.  The
   kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
   /boot/bzImage.  To use the new kernel, save a copy of the old image
   and copy the new image over the old one.  Then, you MUST RERUN LILO
   to update the loading map!! If you don’t, you won’t be able to boot
   the new kernel image.

– Verbose kernel compile/build output:

   Reinstalling LILO is usually a matter of running /sbin/lilo.
   You may wish to edit /etc/lilo.conf to specify an entry for your
   old kernel image (say, /vmlinux.old) in case the new one does not
   work.  See the LILO docs for more information.

Normally, the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers
need
to see compile, link, or other commands exactly as they are executed.
For this, use “verbose” build mode. This is done by inserting
“V=1” in the “make” command. E.g.:

   After reinstalling LILO, you should be all set.  Shutdown the
system,
   reboot, and enjoy!

make V=1 all

   If you ever need to change the default root device, video mode,
   ramdisk size, etc.  in the kernel image, use the ‘rdev’ program (or
   alternatively the LILO boot options when appropriate).  No need to
   recompile the kernel to change these parameters.

To have the build system also tell the reason for the rebuild of each
target, use “V=2”. The default is “V=0”.

 – Reboot with the new kernel and enjoy.

– Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a “make modules_install”.

IF SOMETHING GOES WRONG:

Alternatively, before compiling, use the kernel config option
“LOCALVERSION” to append a unique suffix to the regular kernel
version.
LOCALVERSION can be set in the “General Setup” menu.

 – 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 (torvalds@linux-foundation.org), and possibly to any
other
   relevant mailing-list or to the newsgroup.

– In order to boot your new kernel, you’ll need to copy the kernel
image (e.g. …/linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.

 – 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.

– Booting a kernel directly from a floppy without the assistance of a
bootloader such as LILO, is no longer supported.

 – If the bug results in a message like

If you boot Linux from the hard drive, chances are you use LILO, which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don’t, you won’t be able to boot
the new kernel image.

     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

Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.

   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

After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!

 – 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
   ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/
.
   Alternatively, you can do the dump lookup by hand:

If you ever need to change the default root device, video mode,
ramdisk size, etc. in the kernel image, use the ‘rdev’ program (or
alternatively the LILO boot options when appropriate). No need to
recompile the kernel to change these parameters.

 – 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.

– Reboot with the new kernel and enjoy.

   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:

IF SOMETHING GOES WRONG:

     nm vmlinux | sort | less

– 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 (torvalds@linux-foundation.org), and possibly to any other
relevant mailing-list or to the newsgroup.

   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.

– 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 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.

– If the bug results in a message like

 – Alternatively, 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”).

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

   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.)

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

   gdb’ing a non-running kernel currently fails because gdb (wrongly)
   disregards the starting offset for which the kernel is compiled.

– 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
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/
.
Alternatively, 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.

– Alternatively, 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.

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图
Copyright @ 2010-2019 澳门新葡亰官网app 版权所有