Kernel-header und Kernel dürfen unterschiedliche Versionen haben?

[Zico]

Hi Leute

Da ich als x86_64 und AGP Nutzer auf einen eigenen Kernel angewisen bin habe ich kernel26 auf IgnorePkg gesetzt.
Beim -syu müssen jedoch die Kernel-header geupdated werden, damit glibc eupdated werden kann.

Meine Frage ist jetzt, ob Kernel-header und der Kernel selbst unterschiedlich sein KÖNNEN oder sollte ich diese auch ausschließen? Den Kernel selbst mag ich nicht bei jedem Update selbst compilieren (was ich ja muss).

EDIT:
Abhängigkeitsprobleme gab es bisher nicht, aber die Frage will ich dennoch stellen, bevor ich in Tefeuls Küche komme, wenn die Header auf 2.6.22 springen, während der Kernel noch auf 2.6.21 dümpelt.

 

[supersucker]

Meine Frage ist jetzt, ob Kernel-header und der Kernel selbst unterschiedlich sein KÖNNEN

Ja, können sie, aber sobald irgendwas kernel-relevantes kompilierst - z.B. Treiber - wirst du spätestens da auf die Nase fallen........

 

[Zico]

Hm okay das is natürlich schlecht, da ich eben den selbstgebauten Kernel für den Nvidia Treiber verwende.
Da werd ich mir wohl was anderes einfallen lassen müssen.

 

[blue-dev]

Nein, bei Arch ist das _ganz_ anders.
Ich hab selber meine eigenen Kernel mit massig Veränderungen.
Die kernel-header haben bei Arch eine komplett andere Bedeutung.
Alle Dateien die man zum compilieren neuer Module braucht befinden sich bei Arch bereits im normalen kernel Paket. Das Kernel-header Paket ist überflüssig, es sind nur ein paar Includes für C die nicht gebraucht werden.

Um die einen eigenen Kernel zu bauen solltest du zuerst eine PKGBUILD erstellen, ich empfehle keine aus dem Wiki zu nehmen sondern die Original PKGBUILD vom 2.6.21-arch Kernel, dort passt du ein paar Variablen an, änderst die configs usw.

Edit: Auszug aus der PKGBUILD vom kernel26:

install -D -m644 Makefile \
    $startdir/pkg/usr/src/linux-${_kernver}/Makefile
  install -D -m644 kernel/Makefile \
    $startdir/pkg/usr/src/linux-${_kernver}/kernel/Makefile
  install -D -m644 .config \
    $startdir/pkg/usr/src/linux-${_kernver}/.config
  install -D -m644 .config $startdir/pkg/boot/kconfig26
  mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/include

  mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/arch/$KARCH/kernel
  for i in acpi asm-generic asm-$KARCH config linux math-emu media net pcmcia scsi sound video; do
    cp -a include/$i $startdir/pkg/usr/src/linux-${_kernver}/include/
  done

  # copy files necessary for later builds, like nvidia and vmware
  cp Module.symvers $startdir/pkg/usr/src/linux-${_kernver}
  cp -a scripts $startdir/pkg/usr/src/linux-${_kernver}
  # fix permissions on scripts dir
  chmod og-w -R $startdir/pkg/usr/src/linux-${_kernver}/scripts
  mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/.tmp_versions
  
  cp arch/$KARCH/Makefile $startdir/pkg/usr/src/linux-${_kernver}/arch/$KARCH/
  if [ "$CARCH" = "i686" ]; then
    cp arch/$KARCH/Makefile.cpu $startdir/pkg/usr/src/linux-${_kernver}/arch/$KARCH/
  fi
  cp arch/$KARCH/kernel/asm-offsets.s $startdir/pkg/usr/src/linux-${_kernver}/arch/$KARCH/kernel/

  # add headers for lirc package
  mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/drivers/media/video
  cp drivers/media/video/*.h  $startdir/pkg/usr/src/linux-${_kernver}/drivers/media/video/
  for i in bt8xx cpia2 cx25840 cx88 em28xx et61x251 pwc saa7134 sn9c102 usbvideo zc0301; do
   mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/drivers/media/video/$i
   cp -a drivers/media/video/$i/*.h $startdir/pkg/usr/src/linux-${_kernver}/drivers/media/video/$i
  done
  # add dm headers
  mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/drivers/md
  cp drivers/md/*.h  $startdir/pkg/usr/src/linux-${_kernver}/drivers/md
  # add inotify.h
  mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/include/linux
  cp include/linux/inotify.h $startdir/pkg/usr/src/linux-${_kernver}/include/linux/
  # add CLUSTERIP file for iptables
  mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/net/ipv4/netfilter/
  cp net/ipv4/netfilter/ipt_CLUSTERIP.c $startdir/pkg/usr/src/linux-${_kernver}/net/ipv4/netfilter/
  # add vmlinux
  cp vmlinux $startdir/pkg/usr/src/linux-${_kernver}
  # copy in Kconfig files
  for i in `find . -name "Kconfig*"`; do 
    mkdir -p $startdir/pkg/usr/src/linux-${_kernver}/`echo $i | sed 's|/Kconfig.*||'`
    cp $i $startdir/pkg/usr/src/linux-${_kernver}/$i
  done

  if [ "${KARCH}" = "i386" ]; then
    mkdir ${startdir}/pkg/usr/src/linux-${_kernver}/include/asm-x86_64
    cp -a include/asm-x86_64/tsc.h ${startdir}/pkg/usr/src/linux-${_kernver}/include/asm-x86_64
  else
    mkdir ${startdir}/pkg/usr/src/linux-${_kernver}/include/asm-i386
    cp -a include/asm-i386/tsc.h ${startdir}/pkg/usr/src/linux-${_kernver}/include/asm-i386
  fi

  cd $startdir/pkg/usr/src/linux-${_kernver}/include && ln -s asm-$KARCH asm

  chown -R root.root $startdir/pkg/usr/src/linux-${_kernver}
  cd $startdir/pkg/lib/modules/${_kernver} && \
    (rm -f source build; ln -sf ../../../usr/src/linux-${_kernver} build)
  # for binary modules make prepare
  cd $startdir/pkg/lib/modules/${_kernver}/build
  make prepare

Da werden alle nötigen Sachen direkt kopiert, die ganze PKGBUILD bekommst du wenn du als root "abs" eintippst udn dann in /var/abs/kernels/kernel26 guckst, du solltest dir den Code und die kernel26.install genau angucken weil du unbedingt die mkinitcpio configs übernehmen solltest.

 

[supersucker]

Nein, bei Arch ist das _ganz_ anders.
Ich hab selber meine eigenen Kernel mit massig Veränderungen.
Die kernel-header haben bei Arch eine komplett andere Bedeutung.
Alle Dateien die man zum compilieren neuer Module braucht befinden sich bei Arch bereits im normalen kernel Paket. Das Kernel-header Paket ist überflüssig, es sind nur ein paar Includes für C die nicht gebraucht werden.

Dann hab ich wohl Müll erzählt........

Interessant das arch das anders handhabt als ich es von __allen__ anderen Distros kenne. Wieder was gelernt.......

Die kernel-header haben bei Arch eine komplett andere Bedeutung.

Könntest du - aus Interesse - noch kurz darauf eingehen welche?

 

[blue-dev]

Ja, Arch hat wirklich ein paar Eigenheiten /etc/init.d existiert z.B. auch nicht.
Deswegen brauchten wir auch ein eigenes Forum

Vielleicht noch das zum Thema, die kernel header sind sogar anders gepatched als der eigentliche Kernel (verstehe wer will) und ich würde eigentlich dazu raten das Paket zu löschen, es aktualisiert sich sowieso nur bei jedem 2.6.2x Versionssprung und hat für mich eigentlich keinen Sinn.
Es spielt nur uninteressante Dateien in /usr/include.

 

[Zico]

Naja okay ich sehe auch gerade, dass Kernel im aktuellen Repo auf 2.6.21.6 und die header auf 2.6.21.1 stehen. Vllt kann ich ja dann doch meinen custom Kernel behalten ohne ständig aufpassen zu müssen.

 

[Lesco]

Zwar ist das Problem schon gelöst, aber egal:
Das kernel-headers-Paket ist für userspace-Anwendungen, die (ungeschickterweise) die kernel-header benutzen und dann müssen die header zu der verwendeten glibc und nicht unbedingt zur verwendeten Kernelversion passen, sonst gibt es Probleme.
Die besagten Header liegen auch in /usr/include/linux/...
Die Header für Kernel-Module jedoch in /usr/src/. Die beiden Pakete müssen also keineswegs die selben Versionsnummern haben.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html

von Linus Torvalds
Think about it a bit.. Imagine that the kernel introduces a new "struct
X", and maintains binary backwards compatibility by having an old system
call in the old place that gets passed a pointer to "struct old_X".
It's all compatible, because binaries compiled for the old kernel will
still continue to run - they'll use the same old interfaces they are
still used to, and they obviously do not know about the new ones.

Now, if you start mixing a new kernel header file with an old binary
"glibc", you get into trouble. The new kernel header file will use the
_new_ "struct X", because it will assume that anybody compiling against
it is after the new-and-improved interfaces that the new kernel
provides.

But then you link that program (with the new "struct X") to the binary
library object archives that were compiled with the old header files,
that use the old "struct old_X" (which _used_ to be X), and that use the
old system call entry-points that have the compatibility stuff to take
"struct old_X".

 

[Zico]

Das erklärt zumindest warum das glibc Update auch die HEader mit updaten wollte.

Das ist interessant, danke für die Aufklärung. Man lernt echt nie aus.