2.4 -> 2.6

Конфигурация ядра - переход от 2.4 к 2.6

Ядро - сердце операционной системы , оно управляет тредами, процессами , ресурсами . В отличие от других операционных систем , Линукс позволяет пользователям конфигурировать ядро , при этом можно менять его размер, включать-выключать поддержку различных устройств. Выключение лишних устройств особенно полезно при разработке embedded systems, ведь маленькое ядро требует меньше памяти.

Код устройства , автоматически подгружаемый в ядро, находится как правило в модуле. В этой статье обсуждается как написание новых модулей для 2.6, так и модификация уже существующих.

Конфигурация ядра выполняется с помощью различных конфиг-редакторов. Такой редактор позволяет вам получить информацию о какой-то переменной ядра, выключить-включить ее , вкомпилировать ее в ядро или в отдельный модуль..

Конфигурация ядра - это первый шаг при сборке ядра. Вам потребуется сконфигурировать и собрать модули , определенные в этой конфигурации. Для десктопа это не представляет особых проблем, но все усложняется для других устройств. Например , если вы собираете ядро для embedded systems, вы делаете это на своем десктопе , но при этом вы используете т.н. cross-compiler.

Cross-compilers генерит бинарник для таких систем для другого процессора-архитектуры.. Cross-compiler настраивается через различные переменные в Makefile, или можно использовать софт типа TimeSys TimeStorm.

Появились различные графические редакторы для конфигурации 2.6, которые могут отслеживать зависимости между переменными самого конфига. Рассмотрим 4 команды:

• make config, командный интерфейс
  
  
• make oldconfig, текстовой интерфейс для устаревшей конфигурации
  
  
• make menuconfig, редактор с текстовым гуе-м
  
  
• make xconfig, графический редактор

Figure 1: Sample make xconfig Screen for the 2.6 Kernel
(Click for larger view)

Figure 2: Sample make gconfig Screen

• В меню можно выбрать опцию Show all options , которая покажет все доступные опции.
  
  
• Опция Show debug показывает, что произойдет при активации той или иной опции.
  
  
• Опция меню Show Name показывает имя переменой , ассоциированной с именем опции ядра. Это может быть полезно при определении зависимостей.

# cd /opt/timesys/linux/4.1/iq80315/src/2.4.21-timesys-4.1/kernel
# cp .config /opt/timesys/linux/5.0/iq80315/src/2.6-timesys-5.0/kernel
# cd /opt/timesys/linux/5.0/iq80315/src/2.6-timesys-5.0/kernel
# make oldconfig

#define MODULE
 
#include < linux/module.h>
 
#include < linux/config.h>
 
#include < linux/init.h>

static int __init name_of_initialization_routine(void) {
    /* 
     * code here 
     */
}
static void __exit name_of_cleanup_routine(void) {
    /*
     * code here
     */
}
module_init(name_of_initialization_routine);
module_exit(name_of_cleanup_routine);

 #include < img src="/files/misc/lt.gif">linux/module.h>
 
#include < img src="/files/misc/lt.gif">linux/config.h>
 
#include < img src="/files/misc/lt.gif">linux/init.h>
MODULE_LICENSE("GPL");
static int __init name_of_initialization_routine(void) {
    /* code goes here */
    return 0; 
}
static void __exit name_of_cleanup_routine(void) {
    /* code goes here */
}
module_init(name_of_initialization_routine);
module_exit(name_of_cleanup_routine);

make: Entering directory `/usr/src/linux-2.6.1'
*** Warning: Overriding SUBDIRS on the command line can cause
***          inconsistencies
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
  Building modules, stage 2.
  MODPOST
  CC      /home/wvh/timesys/2.6/testmod/testmod.mod.o
  LD [M]  /home/wvh/timesys/2.6/testmod/testmod.ko
make: Leaving directory `/usr/src/linux-2.6.1'

./configure --prefix=/
make moveold
make
make install

1. Get the latest versions of the ALSA drivers, library, and utilities in source format or as pre-prepared packages that you can install on your system. ALSA drivers are also included in the 2.6 kernel source, but we suggest getting the drivers package so that you can upgrade your 2.4 system to ALSA first, as suggested previously. If you want to use ALSA's OSS emulation mode, you will also need to get its source code and build and install this package as well.
   
2. Configure, compile, and build these packages (if necessary) or install the binaries on your system.
   
3. Configure the ALSA software using the alsaconf application, which probes for your sound hardware, generates the correct module loading information, and optionally updates your /etc/modules.conf file.
   
4. Enable ALSA using the alsamixer application, which un-mutes your ALSA configuration. (ALSA is always initially muted.)
   
5. Link the /etc/rc.d/init.d/alsasound startup file into the sequence of command files executed when your system starts up.
   
6. Execute the generate-modprobe.conf script to migrate your ALSA module configuration to the /etc/modprobe.conf file used with the module utilities required for a 2.6 kernel.

  none   /sys    sysfs    noauto        0 0

VERSION=`uname -a | sed -e 's;.* \(2\.6\).*;\1;'`
if [ "x$VERSION" = "x" ] ; then
        VERSION="2.4"
fi

if [ "x$VERSION" = "x2.6" ] ; then
  action $"Mounting sysfs filesystem: " mount -n -t sysfs /sys /sys
fi

make defconfig ARCH=ppc

1. Perform any mandatory package updates to the compilers and build environment on any desktop system that you use in conjunction with your embedded system. (Explained in the third whitepaper in this series, "Using the 2.6 Kernel with Your Current System".)
   
   
2. Perform any mandatory package updates to any cross-compilers that you are using to build applications for the target system. (Described in third whitepaper in this series, "Using the 2.6 Kernel with Your Current System".)
   
   
3. Migrate any customized kernel configuration to the 2.6 kernel provided with your 2.6-based distribution. (See the first whitepaper in this series, "Customizing a 2.6-Based Kernel".)
   
   
4. Convert any device drivers that you have written to the new device driver model used by the 2.6 kernel (Explained in the second whitepaper in this series, "Migrating Device Drivers to 2.6".)
   
   
5. Perform any mandatory package updates to the applications and utilities used in your existing root filesystem or initial RAM disk.
   
   
6. Migrate any administrative or configuration changes that you have made from your existing root filesystem to the new root filesystem provided with your 2.6-based Linux distribution
   
   
7. Convert your custom applications from your existing root filesystem to the new root filesystem that you will use with your 2.6-based distribution.

(Click to enlarge)

# gunzip initrd.img.gz
# mount -t ext2 -o loop initrd.img /mnt/initrd

Filesystem          1K-blocks  Used Available Use% Mounted on
/tmp/initrd.img     2948       510      2288  19% /mnt/initrd

# cd /mnt/initrd
# ls -al
total 13
drwxr-xr-x     9 root     root         1024 Feb 16 13:31 .
drwxr-xr-x    16 root     root         4096 Mar  3 08:58 ..
drwxr-xr-x     2 root     root         1024 Feb 16 13:31 bin
drwxr-xr-x     2 root     root         1024 Feb 16 13:31 dev
drwxr-xr-x     2 root     root         1024 Feb 16 13:31 etc
drwxr-xr-x     2 root     root         1024 Feb 16 13:31 lib
-rwxr-xr-x     1 root     root          340 Feb 16 13:31 linuxrc
drwxr-xr-x     2 root     root         1024 Feb 16 13:31 loopfs
drwxr-xr-x     2 root     root         1024 Feb 16 13:31 proc
lrwxrwxrwx     1 root     root            3 Feb 16 13:31 sbin -> bin
drwxr-xr-x     2 root     root         1024 Feb 16 13:31 sysroot

#!/bin/nash
echo Mounting /proc filesystem
mount -t proc /proc /proc
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc

mount and examine the initial RAM disk to verify how it uses the /linuxrc file.

if the /linuxrc file is a command script, you will need to check the commands that it executes in order to ensure that they are compliant with your 2.6 kernel. If it specifically references commands such as modprobe or insmod, you will have to make sure that you have installed 2.6-compatible versions of these utilities in your initial RAM disk and any other filesystems that you use. Your initial RAM disk must also contain kernel modules that have been built for the 2.6 kernel, and therefore follow the naming convention required by the 2.6 kernel - using the ".ko" extension rather than the classic ".o" extension.

if the /linuxrc file is a symbolic or hard link to the /sbin/init program, you will need to make sure that the command file used by the init program is not 2.4-specific. If it specifically references commands such as modprobe or insmod, you will have to make sure that you have installed 2.6-compatible versions of these utilities in your initial RAM disk and any other filesystems that you use. Your initial RAM disk must also contain kernel modules that have been built for the 2.6 kernel, and therefore follow the naming convention required by the 2.6 kernel - using the ".ko" extension rather than the classic ".o" extension. The files and execution sequence used by the init process are discussed in the next section of this white paper.

id:2:initdefault:

si::sysinit:/etc/rc.d/rc.sysinit

l2:2:wait:/etc/init.d/rc 2

• you must copy any mandatory loadable kernel modules (LKMs) to any initial RAM disk that you are using. To work with a 2.6 kernel, these must all use the new ".ko" naming convention (and must have been compiled against a 2.6 kernel).
  
  
• the /linuxrc file in an initial RAM disk or any of the files in the generic boot sequence (/etc/inittab) should not contain any explicit module load references that include the old module conventions (i.e., the ".o" vs ".ko" naming conventions.

int pid;
if (pid=fork()) {
  /* parent code */
  exit(1);
} else {
  /* child code */
  execl( "command", "arg1", "arg2", ...);
  printf("Should never get here...\n");
  exit (-1);
}

# export LD_ASSUME_KERNEL=2.4.1

# getconf GNU_LIBPTHREAD_VERSION
linuxthreads-0.10

# getconf GNU_LIBPTHREAD_VERSION
nptl-0.60

If you are building your own toolchain to work with a 2.6 system you must, of course, make sure that you've built the toolchain on a 2.6 system, and that you have enabled NPTL support in the version of the C library used by your toolchain. You will also need recent source codeyou're your C library. For example, if you are building glibc with NPTL support, version 2.3.3 or better of the glibc source is recommended. Enabling NPTL support when building a C library, such as glibc, is analogous to the mechanism used for enabling LinuxThreads support for glibc. This is done by using the configuration option --enable-add-ons=nptl when configuring glibc, rather than --enable-add-ons=linuxthreads. The latest NPTL source code is available here. You will also need a recent version of GCC (3.3.2 or better suggested for x86 platforms, 3.4 suggested for PPC platforms), and a version of binutils that supports the Call Frame Information (CFI) directive (2.14.90.0.7 or better suggested; available here).

In general, if your applications were compiled with earlier versions of GCC, you may notice changes in warning messages, code size, and changes to the options provided by the GCC compiler and the rest of the toolchain. It is especially important to be aware of the potential for increased code size when you are recompiling embedded applications. You may need to take advantage of additional or new optimization options in order to continue to fit your existing applications in resource-constrained environments. Newer versions of GCC are also increasingly conformant to various C and C++ specifications, and are therefore likely to complain about aspects of your application code that earlier versions of these compilers ignored. In general, new warnings from updated compilers should be seen as an opportunity to weed out latent defects.

Newer versions of GCC have also deprecated some machine-specific options (specified using -m) in favor of more general optimization options (specified using -f). This may require that you update values such as the CFLAGS options specified in application Makefiles.

Finally, newer versions of GCC implement optimizations that require them to notice possible alias situations that may have been ignored by earlier compilers. The aliasing issues can be resolved (at some performance cost) by using the no strict aliasing compiler option (-fno-strict-aliasing).

Updating Applications for NPTL

The changes between 2.4's threading support and NPTL provide significant design and performance improvements. NPTL is far more compliant with the POSIX specification than the LinuxThreads package was under 2.4. NPTL also supports useful features such as mutexes that are shared among threads, simplifying resource sharing, conflict prevention, and increasing parallelism. Finally, NPTL is vastly more efficient than 2.4's threading support. Some of the standard performance metrics used at TimeSys have shown NPTL implementations to be up to three orders of magnitude faster than the same code using LinuxThreads.

Some of the more complex changes that you may have to make in your application logic when moving to NPTL are changes related to NPTL's improved support for POSIX signals and signal handling. LinuxThreads implemented generic Unix-style threads, but were limited by various implementation details. NPTL is a POSIX-compliant threading implementation, and therefore handles signals better both between processes and between all threads within those processes. With the NPTL, signals can now be sent from one thread to another, rather than simply on a per-process basis. Signals can also use arguments to transfer information from one thread to another.

Using the NPTL also requires that you make changes to existing code that needs to be able to uniquely identify specific threads. Under LinuxThreads, each thread had a unique process ID (PID). Each thread now shares the PID of its parent process, and the getpid() function therefore returns the same process ID for all threads in a process. With NPTL, a thread's Thread ID must be used to uniquely identify individual threads.

Changes to thread and process IDs also mean that the processes that are traditionally used to spawn processes must now be thread-aware. For example, the exec() functions are now thread-aware, so that a thread inherits the PID of its caller. However, any application that depended on having all threads survive an exec() will need some modification. The parent of a multi-threaded process is notified of a child's termination only when the entire process terminates. Thread-related changes have also been made to the behavior of related fork() calls. For example, functions registered with the pthread_at_fork() function are no longer run when a vfork() occurs.

In addition to changing the internals of thread identification, NPTL does away with the LinuxThreads notion of a manager thread, simplifying the process/thread relationship and eliminating what was essentially administrative overhead under LinuxThreads. This may require application changes if, for example, your application kept track of the number of threads running on its behalf or looked for the manager thread as a signal target.

Finally, using a new threading library means that certain threading functions that were available under LinuxThreads are no longer supported under the NPTL. For example, the pthread_kill_other_threads_np() function is no longer available. This function was used to simulate POSIX-conformant exec() functions. Since the exec() functions themselves are now POSIX conformant, the helper function is not necessary.

For additional information about the design and implementation of the NPTL, a general design and philosophy document is available here.

Conclusion

Changing the kernel that your computer system runs is not necessarily an easy task, but is eminently doable. The white papers in this series have highlighted the issue in configuring the 2.6 kernel, updating device drivers, migrating desktop and custom systems, and updating applications. Certified 2.6-based distributions targeted for embedded use are already available from vendors such as TimeSys, whose 2.6 reference distribution was the first 2.6-based distribution for PPC systems. High-quality commercial software such as TimeSys TimeStorm IDE and TimeStorm Linux Developers Suite (LDS) is designed to help you migrate any Linux kernel, device driver, application, or deployed system to take advantage of the power of the 2.6 kernel and updated packages, threading methodology, and so on.

Linux is a shining example of the power of the Open Source movement as a positive force for change in the software industry. The Linux kernel, the core of any Linux distribution, is constantly evolving to incorporate new technologies and improve performance, scalability, support, and usability. The 2.6 kernel increases the spectrum of systems for which Linux is well-suited, from PDAs, process control systems, and set-top boxes all the way to enterprise servers. The cost, power, and supportability advantages by Linux are more obvious than ever in today's business market and fast-paced technical environment.

Оставьте свой комментарий !
Ваше имя: Комментарий: Оба поля являются обязательными  Автор   Комментарий к данной статье