3.4. Kernel - Update, Libraries, Devices
Was passiert mit den Libraries (glibc), wenn z.B. unter Linux Kernel getauscht
werden, z.B. Version 2.2 gegen 2.4 gegen Version 2.6.
Beim Update von Linux Kernel 2.2 auf 2.4 hat es bei einigen Routinen, die
das Networking betrafen, Veränderungen gegeben. Die Utilities
ifconfig, netstat, ... sowie die GLIBC waren nicht mehr kompatibel,
mußten also gleichzeitg mit einem Kernel - Update ausgetauscht werden. In
Linux Kernel 2.6 hat es verschiedenste Änderungen bei den Devices (nun 65535
Devices möglich, siehe UDEV), beim PROC Mechanismus (Erweiterung auf mehr als 256
Threads je Prozess) und beim logical Volume - Manager (LVM, LVM2) gegeben.
Daher funktionieren nun die Utilities, wie mount nicht
mehr korrekt. Daher ist man dazu übergegangen, sogenannte
Backports durchzuführen, also Utilities mount, umount... so zu
programmieren, daß diese sowohl mit Kernel 2.4 als auch Kernel 2.6
funktionieren, ebenso, wie einige Libraries angepasst werden mußten. Welche
das genau sind, findet man auf www.kerneltrap.org beschrieben.
Wer eine DEBIAN Distribution, wie z.B. Knoppix besitzt, kann ja wahlweise
mit Kernel 2.4 oder Kernel 2.6 booten, oder mit apt-get update; apt-get
dist-upgrade seine komplette Distribution auf den neuesten Stand
bringen - neu booten - fertig. Mehr hierzu siehe Abschnitt 4.2.3.
Beim Wechsel zwischen den verschiedenen Kernel - Versionen (2.4/2.6) ergibt
sich die Frage, woher die Libraries, insbesondere der Linker und die GLIBC
wissen, an welcher Stelle im Linux Kernel sich welche Funktion befindet?
Hierzu muß man wissen, daß der Linker in Linux statisch kompiliert ist, und
beim Start von Programmen auf eine Tabelle zurückgreift, in welcher alle
Funktionen, die der Kernel anbietet, mitsamt Einsprungsadresse aufgelistet
sind:
$ ldd /lib/libc-2.3.1.so
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x30000000)
$ ldd /lib/ld-linux.so.2
statically linked
$
Beim Programmstart wird der Linker beansprucht, der sich von
/boot/System.map die entsprechenden Adressen holt, und
dynamisch beim Start in das Binary oder Library - Routinen einbindet:
$ more /boot/System.map
c0000000 T _start
c0000000 T _stext
c000000c T __start
c000002c t __after_mmu_off
c0000064 t turn_on_mmu
...
Beim Start eines dynamisch gelinkten Programmes erst werden die
Einsprungsadressen so gesetzt, daß sie mit dem neuen Kernel genau
übereinstimmen. Wer also einen neuen Kernel bootet, sollte die Datei
/boot/System.map ebenfalls entsprechend der Kernel - Versionsnummer
angepasst haben:
# ls -la /boot/
total 14736
drwxr-xr-x 2 root root 4096 Dec 4 04:05 .
drwxr-xr-x 23 root root 4096 Nov 18 00:56 ..
-rw-r--r-- 1 root root 559088 Jun 7 2002 System.map-2.4.18-bf2.4
-rw-r--r-- 1 root root 509630 Oct 24 2003 System.map-2.4.20
-rw-r--r-- 1 root root 793561 Nov 8 10:25 System.map-2.6.8
-rw-r--r-- 1 root root 811713 Nov 25 10:46 System.map-2.6.9-1-686
-rw-r--r-- 1 root root 512 Aug 15 2003 boot.0300
-rw-r--r-- 1 root root 512 Sep 18 2003 boot.1600
lrwxrwxrwx 1 root root 11 Jan 26 2004 boot.b -> boot-menu.b
-rw-r--r-- 1 root root 308326 Dec 4 04:04 coffee.bmp
-rw-r--r-- 1 root root 30002 Jun 7 2002 config-2.4.18-bf2.4
-rw-r--r-- 1 root root 17364 Oct 24 2003 config-2.4.20
-rw-r--r-- 1 root root 17364 Oct 24 2003 config-2.4.20.old
-rw-r--r-- 1 root root 56379 Nov 25 09:44 config-2.6.9-1-686
lrwxrwxrwx 1 root root 13 Jun 24 15:48 debian.bmp -> /boot/sid.bmp
-rw-r--r-- 1 root root 153720 Dec 4 04:04 debianlilo.bmp
-rw-r--r-- 1 root root 1040384 Oct 24 2003 initrd.img-2.4.20
-rw-r--r-- 1 root root 974848 Nov 8 10:34 initrd.img-2.6.8
-rw-r--r-- 1 root root 4632576 Dec 4 04:04 initrd.img-2.6.9-1-686
-rw------- 1 root root 59904 Dec 4 04:05 map
-rw-r--r-- 1 root root 23662 Dec 4 04:04 sarge.bmp
-rw-r--r-- 1 root root 24116 Dec 4 04:04 sid.bmp
-rw-r--r-- 1 root root 1263337 Jun 7 2002 vmlinuz-2.4.18-bf2.4
-rw-r--r-- 1 root root 980442 Oct 24 2003 vmlinuz-2.4.20
-rw-r--r-- 1 root root 1482124 Nov 8 10:30 vmlinuz-2.6.8
-rw-r--r-- 1 root root 1231894 Nov 25 10:46 vmlinuz-2.6.9-1-686
#
Eric Raymonds legendärer Beitrag
Die
Kathedrale und der Basar gibt eine gute Vorstellung davon,
wie Softwareentwicklung in einer OpenSource Community betrieben wird.