smart os
It's can run xfce4 in smartos
このプロジェクトは、コンパクトで完全に機能するLinuxオペレーティングシステムを迅速に作成する方法を示しています。プロジェクトアドレスはhttps://github.com/superconvert/smart-osです
生産用にサーバーバージョンを選択するのはなぜですか？
サーバーバージョンには、ウィンドウシステムが依存するパッケージのほとんどは含まれていません。システムにこれらのパッケージが付属している場合、パッケージの複数のバージョン、コンピレーションの問題、依存関係の問題、リンクの問題、ランタイムの問題に問題があり、作業に多くの干渉を引き起こします。さらに、これらの問題を解決することは無意味で、依存関係パッケージの純粋なバージョンが必要です
なぜウィンドウシステムが非常に大きく機能するのですか？
APTを使用してインストールするすべてのパッケージ（ツールを除く）は、理論的には、解決する必要があるパッケージの依存関係と癒着を含むソースコードをコンパイルする必要があります。これは非常に大きなワークロードです。方法はありません。新しいシステムには何もありません。必要な環境を提供する必要があります。プロジェクトAはパッケージBに依存し、パッケージBはパッケージC、パッケージC、パッケージCはパッケージdに依存します。私たちがしなければならないのは、すべてのパッケージをコンパイルすることだけです！
このスクリプトは、Ubuntu 18.04で作成されました。他のシステムはあまり変更されるべきではありません。それを必要とする友達は自分でそれを変更できます。
システム環境を準備します。カーネルをコンパイルする必要があるため、カーネルコンパイルに必要な環境をインストールする必要があります。 Busyboxをコンパイルする必要があるため、必要に応じて必要な環境を自分でインストールできます。
./00_build_env.shソースコードをコンパイルする（カーネル、glibc、busybox、gcc、binutils）
./01_build_src.shシステムディスクを作成します（重要、このステップはシステムをシステムファイルにインストールします）
./02_build_img.shSmart-OSシステムを実行します
./03_run_qemu.sh 或 ./04_run_docker.shオペレーティングシステムを作るのは簡単ですか？ディスクスペースは任意に拡張し、オンラインでアクセスでき、必要に応じて拡張できます。私はそれを正常に試して、Smart-OSでストリーミングサーバーsmart_rtmpdを実行しました
+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+
| 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)Smart-OSはGlibc Dynamicライブラリをインストールするため、これは動的ライブラリローダー/リンカーLD-Linux-X86-64.SO.2に大きく依存しています。アプリケーションは動的コンパイルを通じてリンクされているため、動的リンクを必要とするアプリケーションがオペレーティングシステムによってロードされる場合、システムは必要なすべての動的ライブラリファイルを見つけてロードする必要があります。この作業は、ld-linux.so.2によって行われます。プログラムがロードされると、オペレーティングシステムは、プログラムの通常のエントリアドレスの代わりに、コントロールをLD-LINUX.SOに引き渡します。 LD-LINUX.SO.2は、必要なすべてのライブラリファイルを探してロードし、アプリケーションの開始ポータルへのコントロールを引き渡します。 LD-LINUX-X86-64.SO.2は、実際にはLD-LINUX.SO.2のソフトチェーンです。 /lib64/ld-linux-x86-64.so.2の下に存在する必要があります。それ以外の場合、動的にコンパイルされたBusyboxは、GLIBCライブラリによって異なります。 GLIBCライブラリの負荷には、LD-LINUX-X86-64.SOが必要です。 /lib64ディレクトリに存在しない場合、システムが直接パニスになります。この問題には特別な注意が必要です！ ！ ！
Qemuは一般に、起動後の小さなウィンドウを持っています。エラーが発生すると、基本的にエラーログを読み取る方法はありません。次に、grubのスタートアップアイテムにConsole = ttys0を追加する必要があります。同時に、QEMU-System-X86_64は、シリアルポート出力をファイルに追加します - シリアルファイル：./ QEMU.LOGなので、デバッグははるかに便利です。デバッグ後、コンソール= TTYS0を削除する必要があります。それ以外の場合、/etc/init.d/rcsのコンテンツは表示されない場合があります。
コンパイルしたGLIBCのバージョンは、通常、システムに付属のバージョンよりも高くなります。テストプログラムmain.cを記述して、GLIBCが正常にコンパイルされているかどうかをテストできます。例えば：
# include < stdio.h >
int main () {
printf ( " Hello glibc n " );
return 0 ;
}コンパイルします
gcc -o test main.c -Wl,-rpath=/root/smart-os/work/glibc_install/usr/lib64 ./testプログラムを正常に実行し、通常、この/lib64/libc.so.6：バージョン `glibc_2.28 'に類似したエラーを報告します。実際、これが指定された動的ライブラリローダー/リンカーとシステム環境がない理由です。通常、GLIBCライブラリをコンパイルすると、コンピレーションディレクトリはTestRun.shスクリプトファイルを自動的に生成し、コンピレーションディレクトリでプログラムを実行します。
./testrun.sh ./test これは通常、正常に行われます。また、次の文をスクリプトに保存することもできます。また、テストを実行することも問題ありません。
exec env /root/smart-os/work/glibc_install/lib64/ld-linux-x86-64.so.2 --library-path /root/smart-os/work/glibc_install/lib64 ./test実行可能プログラムによってロードされたライブラリをどのように追跡しますか？ ld_debug = libs ./testを使用するだけです。ライブラリをプリロードし、ライブラリをプリロードしてLD_PRELOADを使用してライブラリをプリロードするように強制します
カイロを編集すると、通常、多くの問題が発生します。カイロコンピレーションに問題がある場合はどうすればよいですか？一部のエラーメッセージは、インターネットで検索するのが難しいため、コンピレーション中に生成されたconfig.logファイルを確認します。エラーメッセージは非常に詳細です！迅速な情報に従って問題を解決できます
BushboxのINITシステム変数については、Grubのカーネルパラメーターが使用されていても、環境変数を渡すことはできません。 Buyseboxのinitは、デフォルトの環境変数パスを自動的に生成するため、ソースコードをカスタマイズされたパスをサポートするために変更する必要があります。もちろん、シェルのログインモードは /etc /プロファイルを読み取ります。非ロジンモードの場合、このモードは無効であるため、パス /etc /プロファイルに制限があります。
この知識には、比較的大きな知識が含まれます。海外を含む中国でXFCE4の編集と使用を具体的に導入する記事は比較的少ない。また、石を感じて川を渡り、この知識を明確に実証しようとしました。これを説明するために特別な章を開きます。 Smart-OSへのXFCE4移植の場合、グラフィックシステムの秘密を中国人に明らかにします。詳細については、XFCE4.MDを参照してください。
グラフィックシステム全体の統合ワークロードは、システムのすべての側面を含む特に巨大です。海外のこの側面に関する体系的な情報は比較的少なく、中国ではほぼ少ない。目標は、すべての環境と個人的なオープンソースプロジェクトをDIYして、グラフィックシステム全体をそのまま実行させることです。 Smart-OSは最初のものではありませんが、基本的にはトップ3です。私にはまだ分かりません。統合プロセス全体が非常に長く、多くの問題が発生しました。継続的なデバッグとコンピレーションを通じて、これらの繰り返しのタスクについては話しません。ワークロードは特に巨大です。私は自分の仕事を一生懸命説明することができます。私の仕事を説明するのは絶対に誇張ではありません。第二に、私は多くの知識ポイントに遭遇しましたが、その多くは学習し、すぐに販売されました。作業メカニズムを迅速に理解し、問題を引き起こし、問題を解決する必要がありました。全体的なアイデアについて大まかに話しましょう。これにより、新しい学者がアイデアを迅速に理解し、システムのメンテナンスに関するガイダンスを提供し、システムの問題を解決するためのモデルを提供するようになります。
USRディレクトリには、USR = UNIXシステムリソースの略語が詳述されています。 /libライブラリはカーネルレベルのライブラリで、 /usr /libはシステムレベルのライブラリであり、 /usr /local /libはアプリケーションレベルのライブラリです。 /libには、 /bin && /sbinの実行可能プログラムで使用される多くのライブラリが含まれています。 /usr/libシステム実行可能プログラムで参照されるほぼすべてのライブラリがここにインストールされています。
Ramfs：
RAMFSは非常にシンプルなファイルシステムです。 Linuxカーネルの既存のキャッシュメカニズムを直接利用します（そのため、その実装コードは非常に小さいです。このため、RAMF機能はカーネル構成パラメーターを介してブロックすることはできません。これはカーネルの自然特性です）。システムの物理メモリを使用して、動的サイズのメモリベースのファイルシステムを作成します。システムはそれをリサイクルせず、ルートユーザーのみを使用します。
TMPFS：
TMPFSはRAMFの派生物であり、容量制限を追加し、RAMFに基づいてスワップにデータを書き込むことができます。これら2つの機能が追加されているため、通常のユーザーはTMPFを使用することもできます。 TMPFSは仮想メモリを占有し、すべてのRAMではなく、そのパフォーマンスはRAMFほど高くないかもしれません
ラムディスク：
Ramdiskは、メモリ内の領域を物理的なディスクとして使用するテクノロジーです。また、Ramdiskは、ファイルシステムを保存するためのメモリに作成されたブロックデバイスであると言えます。ユーザーの場合、RamDiskは通常のハードディスクパーティションで平等に扱うことができます。システムはまた、対応するキャッシュをメモリに保存し、CPUキャッシュを汚染し、パフォーマンスが低いため、対応するドライバーサポートが必要です。
rootfs：
rootfsは、特定のRAMF（またはTMPFS、TMPFSが有効になっている場合）のインスタンスであり、Linux2.6システムには常に存在します。 rootfsをアンインストールすることはできません（空のリンクされたリストを維持するための特別なコードを追加するのではなく、常にrootfsノードを追加する方が良いので、カーネルのメンテナンスに便利です。rootfsはramfの空のインスタンスであり、スペースはほとんどありません）。他のほとんどのファイルシステムはrootfにインストールされ、それを無視します。ルートファイルシステムのカーネルスタートアップ初期化です。
rootfは、仮想rootfと実際のrootfに分割されます。
仮想rootfは、カーネル自体によって作成およびロードされ、メモリにのみ存在します（その後のinitramfsもこのベースで実装されます）、そのファイルシステムはTMPFSタイプまたはRAMFタイプです。
実際のrootfsとは、ルートファイルシステムがストレージデバイスに存在することを意味します。起動プロセス中に、カーネルはこのストレージデバイスを仮想rootfsにマウントし、 /ディレクトリノードをこのストレージデバイスに切り替えます。このようにして、ストレージデバイスのファイルシステムはルートファイルシステムとして使用され（後続のinitramdiskがこのベースで実装されます）、そのファイルシステムタイプはより豊富で、特定のストレージデバイスのタイプによって決定されるext2、yaffs、yaffs2などです。
スタートアップファイルシステムは、実際にはrootfのファイルを準備することで、カーネルが必要に応じて実行できるようにします。初期のLinuxシステムでは、通常、Linuxルートファイルシステムのストレージデバイスとしてハードディスクまたはフロッピーディスクのみが使用されていたため、これらのデバイスのドライバーをカーネルに簡単に統合できます。ただし、今日の組み込みシステムでは、ルートファイルシステムは、SCSI、SATA、U-Diskなどを含むさまざまなストレージデバイスに保存される場合があります。したがって、これらのデバイスのすべてのドライバーコードをカーネルにコンパイルすることは明らかにそれほど便利ではありません。カーネルモジュール自動荷重メカニズムUDEVでは、UDEVDがカーネルモジュールの自動負荷を実現できることがわかります。そのため、ルートファイルシステムを保存するストレージデバイスのドライバーが自動負荷を実現できる場合、それは素晴らしいことです。ただし、ここには矛盾があります。 udevdは実行可能ファイルです。ルートファイルシステムがマウントされる前にUDEVDを実行することは不可能です。ただし、UDEVDが起動しない場合、ルートファイルシステムデバイスを保存するドライバーは自動的にロードできず、対応するデバイスノードを /devディレクトリに確立できません。この矛盾を解決するために、Ramdiskベースのinitrd（ブートローダー初期化されたRAMディスク）が出現しました。 Initrdは、圧縮された小さなルートディレクトリです。このディレクトリには、必要なドライバーモジュール、実行可能ファイル、スタートアップスクリプトがスタートアップ段階で含まれており、UDEVD（UDEVメカニズムを実装するデーモン）も含まれています。システムが起動すると、ブートローダーはinitrdファイルをメモリに読み取り、メモリ内のinitrdファイルの開始アドレスとサイズをカーネルに渡します。初期化プロセス中に、カーネルはinitrdファイルを解凍し、解凍されたinitrdをルートディレクトリとしてマウントし、ルートディレクトリで /initスクリプトを実行します（cpio形式のinitは /initで、initrd <initrd <initrd of old block devicesまたはinitrd in comiessional file mirrar> is /init -rc）。このスクリプトのinitrdファイルシステムでudevdを実行し、デバイスを保存するためのレアフ（実際のファイルシステム）ドライバーを自動的にロードし、 /devディレクトリに必要なデバイスノードを確立することができます。 udevdがディスクドライバーを自動的にロードした後、実際のルートディレクトリをマウントしてこのルートディレクトリに切り替えることができます。
