Es könnte eine inkohärente Frage zu Kernel-Headern sein, da ich kein klares Verständnis davon habe und nicht weiß, wo und wie sie verwendet werden. Ich denke, sie könnte abgelehnt werden. Meine Frage besteht aus 3 Teilen:
Ich denke, Kernel-Header stellen eine Schnittstelle bereit, damit andere Teile des Kernels, wie Module, sie verwenden können. Das ist mein theoretisches Wissen. Ich habe keinen Code gesehen oder gefunden, der Kernel-Header verwendet (ich wäre dankbar, wenn mich jemand darauf hinweisen könnte). Kann er auch im Userspace verwendet werden? Jedes Codebeispiel wäre willkommen.
Ich habe herausgefunden, dass die Verwendung von
make headers_installKernel-Headern im Userspace möglich ist, gleichzeitig aber davon abgeraten wird, Kernel-Header im Userspace zu verwenden. Wenn davon abgeraten wird, welchen Sinn hat es dann, sie im Userspace verfügbar zu machen?GemäßDasUndDas, Kernel-Headerdateien (.h-Dateien) sollten an drei Stellen vorhanden sein: a.
/usr/include/linux/kernel.hdie für den Benutzerbereich vorgesehen sind b./lib/modules/$(uname -r)/build/include/linux/sched.hdie für externe Module sind c./usr/src/...die für Kernelmodule verwendet werden Bedeutet das, dass Headerdateien in unterschiedlichen Verzeichnissen unterschiedliche Zwecke oder unterschiedliche Schnittstellen oder Signaturen haben? Mit anderen Worten: Hat#include <linux/xyz.h>Code im Benutzerbereich eine andere Bedeutung als#include <linux/xyz.h>in einem Kernelmodul? Und ist ein externes Modul dasselbe wie ein Kernelmodul?
Danke.
Antwort1
Willkommen bei Unix & Linux StackExchange!
Ja, die Kernel-Header stellen eine Schnittstelle für andere Teile des Kernels bereit – da haben Sie völlig recht. Sie enthalten auch Definitionen für die Schnittstelle zwischen dem Kernel und dem Userspace – aber normalerweise wird die „rohe“ Kernel-Schnittstelle nicht direkt verwendet, sondern (oft glibc) über die C-Bibliothek.
Die Userspace-Kernel-Schnittstelle kann aus Gründen der Abwärtskompatibilität mehrere Versionen eines bestimmten Systemaufrufs enthalten. Indem der Systemaufruf über die C-Bibliothek erfolgt, erhalten alle Anwendungen dieselbe Version des tatsächlichen Systemaufrufs und damit eine Garantie für konsistentes Verhalten. Wenn der relevante Teil der Kernel-Schnittstelle aktualisiert wird, müssen Sie außerdem nur die C-Bibliothek aktualisieren, um die neuen Funktionen nutzen zu können.
(Wenn beispielsweise time_t in 32-Bit-Architekturen auf 64 Bit erweitert wird, um das Y2K38-Problem zu vermeiden, kann die C-Bibliothek dazu übergehen, immer die 64-Bit-Version der Kernelschnittstelle zu verwenden, aber eine vom Benutzer konfigurierbare Zuordnung für Anwendungen bereitzustellen, die noch die 32-Bit-Version verwenden. An diesem Punkt können die Funktionen, die 32-Bit-time_t verwenden, veraltet sein und aus dem Kernel entfernt werden, und die C-Bibliothek kann bessere Workarounds für ältere Anwendungen bereitstellen, die noch den 32-Bit-Typ verwenden.)
Sofern Sie nicht auch Ihre eigenen Versionen der C-Bibliothek kompilieren, sollten Sie im Allgemeinen die Entwicklungsheader der C-Bibliothek bevorzugen, anstatt die Kernel-Header direkt zu verwenden.
Die Header werden im /usr/include/linux/Allgemeinen mit dem Entwicklungsheaderpaket der C-Bibliothek geliefert und beschreiben die Version des Kernels, für den die C-Bibliothek kompiliert wurde. Dies ist, was ein Userspace-Anwendungsentwickler normalerweise benötigt.
/lib/modules/$(uname -r)/buildist oft ein symbolischer Link zu /usr/src/...dem Ort, an dem die Header oder der vollständige Quellcode der aktuell ausgeführten Kernelversion gespeichert sind. Es wird beim Kompilieren externer (auch Drittanbieter-)Kernelmodule verwendet, d. h. Kernelmodule aus Quellen, die nicht in den Hauptkernel-Quellcode integriert sind. Diese Header enthalten die erforderlichen Kernel-API-Versionssignaturen, damit die Module versionsspezifische kernelinterne APIs verwenden können.