smart os
It's can run xfce4 in smartos
Dieses Projekt zeigt, wie schnell ein kompaktes und voll funktionsfähiges Linux -Betriebssystem erstellt wird. Die Projektadresse lautet https://github.com/superconvert/smart-os
Warum wählen wir die Serverversion für die Produktion?
Die Serverversion enthält nicht die meisten Pakete, von denen das Fenstersystem abhängt. Wenn das System mit diesen Paketen ausgestattet ist, gibt es Probleme mit mehreren Versionen des Pakets, Kompilierungsproblemen, Abhängigkeitsproblemen, Verbindungsproblemen und Laufzeitproblemen, die unsere Arbeit stark beeinträchtigen. Darüber hinaus ist die Lösung dieser Probleme bedeutungslos, wir brauchen reine Versionen von Abhängigkeitspaketen
Warum funktioniert das Fenstersystem so groß?
Alle Pakete (außer Tools), die wir mit APT installieren, müssen wir den Quellcode, einschließlich der Abhängigkeiten und Adhäsionen des Pakets, die gelöst werden müssen, kompilieren. Dies ist eine äußerst große Arbeitsbelastung. Es gibt keine Möglichkeit, es gibt nichts auf dem neuen System, und die erforderliche Umgebung muss von uns bereitgestellt werden. Project A hängt vom Paket B, dem Paket B ab, hängt vom Paket C, dem Paket C und dem Paket C ab, das vom Paket d abhängt. Wir müssen nur alle Pakete kompilieren!
Dieses Skript wurde auf Ubuntu 18.04 gemacht. Andere Systeme sollten nicht viel verändert werden. Freunde, die es brauchen, können es selbst ändern.
Bereiten Sie die Systemumgebung vor. Da der Kernel zusammengestellt werden muss, müssen Sie die für die Kernel -Kompilierung erforderliche Umgebung installieren. Da BusyBox zusammengestellt werden muss, können Sie die erforderliche Umgebung bei Bedarf selbst installieren.
./00_build_env.shKompilierer Quellcode (Kernel, Glibc, Busybox, GCC, Binutils) kompilieren
./01_build_src.shErstellen Sie eine Systemscheibe (wichtig, in diesem Schritt wird das System in eine Systemdatei installiert).
./02_build_img.shFühren Sie das Smart-OS-System aus
./03_run_qemu.sh 或 ./04_run_docker.shIst es einfach, ein Betriebssystem zu erstellen? Der Speicherplatz kann willkürlich erweitert werden, kann online zugegriffen werden und bei Bedarf erweitert werden. Ich habe es erfolgreich ausprobiert und den Streaming Server Smart_Rtmpd in Smart-Os ausgeführt
+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+
| Host | Container 1 | Container 2 |
| | | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| | Newwork Protocol Stack | | | Newwork Protocol Stack | | | Newwork Protocol Stack | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| + + | + | + |
| ............... | .................... | ........................... | ................... | ..................... | .................... | .................... |
| + + | + | + |
| +-------------+ +---------------+ | +---------------+ | +---------------+ |
| | 192.168.0.3 | | 192.168.100.1 | | | 192.168.100.6 | | | 192.168.100.8 | |
| +-------------+ +---------------+ +-------+ | +---------------+ | +---------------+ |
| | eth0 | | br0 | < --- > | tap0 | | | eth0 | | | eth0 | |
| +-------------+ +---------------+ +-------+ | +---------------+ | +---------------+ |
| + + + | + | + |
| | | | | | | | |
| | + +------------------------------+ | | |
| | +-------+ | | | |
| | | tap1 | | | | |
| | +-------+ | | | |
| | + | | | |
| | | | | | |
| | +-------------------------------------------------------------------------------------------+ |
| | | | |
| | | | |
+--------------- | ------------------------------------------------+-----------------------------------------+-----------------------------------------+
+
Physical Network (192.168.0.0/24)Da Smart-Os die dynamische GLIBC-Bibliothek installiert, stützt sich dies stark auf den dynamischen Bibliothekslader/Linker LD-Linux-X86-64.SO.2. Da Anwendungen durch dynamische Kompilierung verknüpft sind, muss das System, wenn eine Anwendung, die eine dynamische Verknüpfung benötigt, alle dynamischen Bibliotheksdateien, die es benötigt, lokalisieren und laden muss. Diese Arbeit erfolgt von ld-linux.so.2. Wenn das Programm geladen ist, überreicht das Betriebssystem die Kontrolle an LD-Linux. Anstelle der normalen Einstiegsadresse des Programms. LD-Linux.so.2 sucht und lädt alle erforderlichen Bibliotheksdateien und übergeben dann das Startportal der Anwendung. LD-Linux-X86-64.SO.2 ist tatsächlich die weiche Kette von LD-Linux.so.2. Es muss unter /lib64/ld-linux-x86-64.so.2 existieren. Andernfalls hängt unsere dynamisch kompilierte Busybox von der GLIBC -Bibliothek ab. Die Belastung der GLIBC-Bibliothek erfordert LD-Linux-X86-64.SO. Wenn es im Verzeichnis /lib64 nicht vorhanden ist, wird das System direkt in die Luft gerührt. Dieses Problem braucht besondere Aufmerksamkeit! ! !
QEMU hat im Allgemeinen ein kleines Fenster nach dem Start. Sobald ein Fehler auftritt, gibt es im Grunde keine Möglichkeit, das Fehlerprotokoll zu lesen. Dann müssen Sie dem Startelement von GRUB CONSOL = TTYS0 hinzufügen. Gleichzeitig fügt QEMU-System-X86_64 die serielle Portausgabe der Datei-Seriendatei hinzu: ./ Qemu.log, daher ist das Debuggen viel bequemer. Nach dem Debuggen müssen Sie Console = ttys0 entfernen. Andernfalls können der Inhalt in /etc/init.d/RCS nicht angezeigt werden.
Die von uns zusammengestellte Version von GLIBC ist normalerweise höher als die mit dem System gelieferte Version. Wir können ein Testprogramm main.c schreiben, um zu testen, ob GLIBC erfolgreich zusammengestellt wird. Zum Beispiel:
# include < stdio.h >
int main () {
printf ( " Hello glibc n " );
return 0 ;
}Wir kompilieren
gcc -o test main.c -Wl,-rpath=/root/smart-os/work/glibc_install/usr/lib64 Wir führen das Programm ./Test erfolgreich aus und melden normalerweise einen ähnlichen Fehler wie /lib64/libc.so.6: Version `glibc_2.28 'nicht gefunden oder die Programmsegmente direkt. In der Tat ist dies der Grund, warum es keinen bestimmten dynamischen Bibliothekslader/Linker und Systemumgebung gibt. Wenn wir die GLIBC -Bibliothek kompilieren, generiert das Kompilierungsverzeichnis normalerweise automatisch eine TestRun.sh -Skriptdatei und wir führen das Programm im Kompilierungsverzeichnis aus.
./testrun.sh ./test Dies geschieht normalerweise erfolgreich. Wir können den folgenden Satz auch in ein Skript speichern, und es ist auch in Ordnung, den Test auszuführen.
exec env /root/smart-os/work/glibc_install/lib64/ld-linux-x86-64.so.2 --library-path /root/smart-os/work/glibc_install/lib64 ./testWie verfolgen wir, welche Bibliotheken von einem ausführbaren Programm geladen wurden? Verwenden Sie einfach ld_debug = libs ./test. Wir laden die Bibliothek vor und erzwingen die Bibliothek, um LD_PRELAD zu verwenden, um die Bibliothek vorzuladen
Wenn wir Kairo zusammenstellen, stoßen wir normalerweise auf viele Probleme. Was sollen wir tun, wenn es ein Problem mit der Zusammenstellung von Kairo gibt? Einige Fehlermeldungen sind im Internet schwer zu suchen, um die während der Kompilierung generierte Konfiguration zu sehen. Die Fehlermeldungen sind sehr detailliert! Sie können das Problem entsprechend den schnellen Informationen lösen
In Bezug auf die Init -System -Variablen von Busybox ist es nicht möglich, Umgebungsvariablen zu übergeben, auch wenn die Kernel -Parameter von GRUB verwendet werden. Der Init von BusyBox generiert automatisch den variablen Pfad der Standardumgebung, sodass der Quellcode geändert werden muss, um angepasste Pfade zu unterstützen. Natürlich liest der Anmeldemodus der Shell /etc /Profil. Für den Nicht-Login-Modus ist dieser Modus ungültig, sodass die Übergabe von /etc /Profil einschränken.
Dieses Wissen beinhaltet relativ großes Wissen. Es gibt relativ wenige Artikel, die speziell die Zusammenstellung und Verwendung von XFCE4 in China einführen, einschließlich im Ausland. Ich überquerte auch den Fluss, indem ich die Steine spürte und versuchte, dieses Wissen klar zu demonstrieren. Ich werde ein spezielles Kapitel eröffnen, um dies zu erklären. Für die XFCE4-Transplantation in Smart-Os wird es den Chinesen die Geheimnisse des Grafiksystems bekannt geben. Weitere Informationen finden Sie unter XFCE4.MD.
Die Integrationsarbeitslast des gesamten Grafiksystems ist besonders enorm und umfasst alle Aspekte des Systems. Es gibt relativ wenig systematische Informationen zu diesem Aspekt im Ausland und in China fast noch weniger. Ziel ist es, alle Umgebungen und persönlichen Open -Source -Projekte zu DIY zu DIY, um das gesamte Grafiksystem intakt zu machen. Smart-Os ist nicht der erste, aber im Grunde die Top Drei. Ich weiß es noch nicht. Der gesamte Integrationsprozess ist sehr lang, und ich habe viele Probleme gestoßen. Ich werde nicht über diese sich wiederholenden Aufgaben durch kontinuierliches Debuggen und Zusammenstellen sprechen. Die Arbeitsbelastung ist besonders groß. Ich kann meine Arbeit fast schwer beschreiben. Es ist absolut keine Übertreibung, meine Arbeit zu beschreiben. Zweitens habe ich auf viele Wissenspunkte gestoßen, von denen viele sofort gelernt und verkauft wurden. Ich musste den Arbeitsmechanismus schnell verstehen, das Problem verursachen und dann das Problem lösen. Lassen Sie uns grob über die Gesamtidee sprechen, die den neuen Wissenschaftlern dazu ermöglicht, die Ideen schnell zu verstehen, die Wartung von Systemen zu berücksichtigen und ein Modell zur Lösung von Systemproblemen zu liefern.
Das USR -Verzeichnis beschreibt die Abkürzung von USR = UNIX -Systemressource. Die /lib-Bibliothek ist eine Bibliothek auf Kernelebene, /usr /lib ist eine Bibliothek auf Systemebene, und /usr /local /lib ist eine Bibliothek auf Bewerbungsebene. /lib enthält viele Bibliotheken, die von ausführbaren Programmen in /bin && /sbin verwendet werden. /usr/lib Fast alle Bibliotheken, auf die sich ausführbare Programme verweisen
RAMFS:
RAMFS ist ein sehr einfaches Dateisystem. Es wird direkt den vorhandenen Cache -Mechanismus des Linux -Kernels verwendet (so ist sein Implementierungscode sehr gering. Aus diesem Grund kann die RAMFS -Funktion nicht über Kernelkonfigurationsparameter blockiert werden. Es ist eine natürliche Eigenschaft des Kernels). Es verwendet den physischen Speicher des Systems, um ein speicherbasiertes Dateisystem mit dynamischer Größe zu erstellen. Das System recycelt es nicht und nur Root -Benutzer verwenden es.
tmpfs:
TMPFS ist ein Derivat von RAMFs, das Kapazitätsgrenzen hinzufügt und ermöglicht, dass Daten an Swaps basierend auf RAMFs geschrieben werden. Aufgrund der Hinzufügung dieser beiden Funktionen können gewöhnliche Benutzer auch TMPFs verwenden. TMPFS nimmt einen virtuellen Speicher ein, nicht alle RAM, und seine Leistung ist möglicherweise nicht so hoch wie RAMFs
Ramdisk:
Ramdisk ist eine Technologie, die einen Bereich im Gedächtnis als physische Festplatte verwendet. Es kann auch gesagt werden, dass RamDisk ein Blockgerät ist, das in einem Speicher zum Speichern von Dateisystemen erstellt wurde. Für Benutzer kann RAMDISK mit der üblichen Festplattenpartition gleich behandelt werden. Das System speichert auch einen entsprechenden Cache im Speicher, um den CPU -Cache, die schlechte Leistung und die entsprechende Unterstützung des Treibers zu verschmutzen.
rootfs:
RootFS ist eine Instanz spezifischer RAMFs (oder TMPFs, wenn TMPFS aktiviert ist), es existiert immer in Linux2.6 -Systemen. RootFs kann nicht deinstalliert werden (anstatt einen speziellen Code hinzuzufügen, um leere verknüpfte Listen zu verwalten, ist es besser, immer RootFS -Knoten hinzuzufügen. Daher ist es für die Wartung von Kernel bequem. RootFs ist eine leere Instanz von RAMFs und nimmt nur sehr wenig Platz ein). Die meisten anderen Dateisysteme sind auf RootFs installiert und ignorieren sie dann. Es ist die Kernel -Startup -Initialisierung des Stammdateisystems.
RootFs sind in virtuelle RootFs und reale RootFs unterteilt.
Die virtuellen RootFs werden vom Kernel selbst erstellt und geladen und existieren nur im Speicher (die nachfolgende Initramfs wird ebenfalls auf dieser Grundlage implementiert), und sein Dateisystem ist vom Typ TMPFS -Typ oder RAMFS -Typ.
Real RootFs bedeutet, dass das Stammdateisystem auf dem Speichergerät vorhanden ist. Während des Startvorgangs montiert der Kernel dieses Speichergerät auf den virtuellen RootFs und wechselt dann den / Verzeichnisknoten auf dieses Speichergerät. Auf diese Weise wird das Dateisystem auf dem Speichergerät als Root -Dateisystem verwendet (die nachfolgende InitramDisk wird auf dieser Grundlage implementiert), und seine Dateisystemtypen sind reichhaltiger, was ext2, yaffs, yaffs2 usw. sein kann, die durch den Typ des spezifischen Speichergeräts bestimmt werden.
Unser Start -Datei -System besteht tatsächlich darin, Dateien für RootFs vorzubereiten, damit der Kernel nach Belieben ausführen kann. In frühen Linux -Systemen wurden im Allgemeinen nur Festplatten oder Diskettenscheiben als Speichergeräte für das Linux -Root -Dateisystem verwendet, sodass die Treiber dieser Geräte in den Kernel integriert werden können. In den heutigen eingebetteten Systemen kann das Stammdateisystem jedoch auf verschiedenen Speichergeräten gespeichert werden, einschließlich SCSI, SATA, U-Disk usw. Daher ist es offensichtlich nicht sehr bequem, alle Treibercode dieser Geräte in den Kernel zu kompilieren. Im Kernel -Modul Automatischer Lademechanismus Udev sehen wir, dass Udevd das automatische Laden des Kernel -Moduls erkennen kann. Wir hoffen, dass wenn der Treiber des Speichergeräts das Speichern des Root -Dateisystems auch das automatische Laden realisieren kann, das wäre großartig. Hier gibt es jedoch einen Widerspruch. Udevd ist eine ausführbare Datei. Es ist unmöglich, UDEVD auszuführen, bevor das Stammdateisystem montiert ist. Wenn UDEVD jedoch nicht gestartet wird, kann der Treiber, der das Root -Dateisystem -Gerät speichert, nicht automatisch geladen werden und der entsprechende Geräteknoten kann im Verzeichnis /Dev nicht festgelegt werden. Um diesen Widerspruch zu lösen, entstand ein RamDisk-basierter Initrd (Bootloader initialisierter RAM-Disk). Initrd ist ein verdichtetes kleines Wurzelverzeichnis. Dieses Verzeichnis enthält die erforderlichen Treibermodule, ausführbaren Dateien und Startskripte in der Startphase und enthält auch den UDEVD (Dämon, der den UDEV -Mechanismus implementiert). Wenn das System startet, wird der Bootloader die Initrd -Datei in den Speicher lesen und dann die Startadresse und Größe der initrd -Datei im Speicher an den Kernel übergeben. Während des Initialisierungsprozesses dekomprimiert der Kernel die Initrd -Datei und montiert dann das unzippierte Initrd als Stammverzeichnis und führt dann das /init -Skript im Stammverzeichnis aus (init im CPIO -Format ist /init, während initrd im Bildformat <initrd von alter Block Devices oder initrd in traditionellem Dateispiegel -Format> is /initrc). Sie können UDEVD im Initrd -Dateisystem in diesem Skript ausführen. Lassen Sie es automatisch RealFS -Treiber (Real File System) zum Speichern des Geräts laden und die erforderlichen Geräteknoten im Verzeichnis /dev festlegen. Nachdem Udevd den Festplatten -Treiber automatisch geladen hat, können Sie das reale Root -Verzeichnis montieren und in dieses Root -Verzeichnis wechseln.
