本質的にlibcだけの埋め込み可能なOSについて聞いたのを覚えています(多分それはc ++をサポートしていました)。カーネル、パイプ、またはOSに期待するその他のものはありませんでした。ウィキペディアで探してみましたが、リストに表示されませんでした。
そのようなOSは存在しますか?VMの外部と通信するために端末のみまたはC/C ++ +(tcp)ソケットのいずれかをサポートするOSはありますか?それはおもちゃとして私にとって役立つでしょう。
この名前が見つからない理由は、オペレーティングシステムではなく、オペレーティングシステムがないためです。多くの場合、これは「ベアメタル」プログラミングのようなものと呼ばれます。
ベアメタルプログラミングの一般的な考え方は、ボード上にメモリコントローラやその他のハードウェアをセットアップし、プログラムに制御を移す汎用コード( 「ブートローダー」)が少しあるということです。 。(オペレーティングシステムにもブートローダーがあるため、その意味で、プログラムがオペレーティングシステムに取って代わります。) Ubootはかなり一般的なオープンソースのブートローダーであるため、情報を探すのに適した場所です。
ベアメタルプログラミングのトリッキーな点の1つは、ハードウェア通信を処理するオペレーティングシステムがないため、「データが送信される限り、printfは実際には何を意味するのか」を考える必要があるということです。どんな周辺機器?」と「どうやってそこに行かせるの?」繰り返しになりますが、一部のブートローダーはこの種のサポートを提供しますが、すべてを接続することは必ずしも簡単ではありません。繰り返しますが、Ubootは良い例です。
一方、Cライブラリ自体は、ブートローダーではなく、実際にはコンパイラによって提供されます。
(名前のメモとして追加する必要があります:私が働いている会社は、 Sourcery CodeBenchとして知られる一連のベアメタルおよびLinuxコンパイラを作成しています。CodeBenchの場合、ベアメタルバージョンは通常、使用するABI仕様にちなんで名付けられています。プログラムをリンクしているので、「ELF」または「EABI」バージョンはすべてベアメタルコンパイラです。これは、この種のことを指す非常に一般的な方法だと思います。そのため、この種の名前も表示されます。)
私はあなたの仮定のいくつかに問題があると思います。OSにカーネルは必要ないと言っているのは正しいですが、アプリケーションを実行できるものはすべてlibcで静的にコンパイルできます。
参照:http ://www.superfrink.net/athenaeum/OS-FAQ/os-faq-libc.html
たとえば、OS用にその関数をコンパイルする限り、printfを使用することができます。したがって、libcをビルドする限り、MenuetOSを使用できます。
現在、http://pdclib.rootdirectory.de/に小さなバージョンのlibcがあり、これを一部の組み込みシステムで使用できます。
このように、小さなOSはlibcを実行するためのOSと見なすことができます。
基本的にカーネルは必要ありませんが、最小限のOSを検索している場合は、http: //wiki.osdev.org/Projectsから始めることができます。基本的なことをサポートし、フットプリントが小さい趣味やセミプロのプロジェクトがたくさんあります。また、自分で作成するための優れたチュートリアルもいくつかあります。また、ネットワークやシリアルI/Oなどの単純なものにはドライバなどが必要であることも考慮する必要があります。
また、Linuxカーネルは常に良いスタートです(しばらく前に、約20MBのLinuxディストリビューションがありました)
それらはたくさんあります。
ほとんどのプロフェッショナルリアルタイムオペレーティングシステム(RTOS)には、多かれ少なかれ完全なCライブラリの実装が付属しており、多くの場合、C ++(Keil MDK、µItronなど)でも実装されています。実際には、利用可能なリソースを使いすぎるため、回避する傾向があります。
RTOSは通常、ファイルやパイプをサポートしていない非常に小さなカーネルを持っています。代わりに、タスク、タイマー、キュー、イベントフラグをサポートする傾向があり、オーバーヘッドはほとんどありません。
Libccはオペレーティングシステムではありません。OSの定義はやや曖昧ですが、API以上のものが含まれています。メモリ管理、プロセススケジューリングなどが必要です。
Newlibの最小限の実行可能な例
https://sourceware.org/newlib/
Newlibを使用すると、ベアメタルプラットフォーム用の独自のシステムコールを実装できます。
ここでは、QEMUAarch64で実行されているcrosstool-NGで構築されたNewlibを示す高度に自動化された文書化された例を提供します。
たとえば、上記の例では、サンプルプログラムがありexit.c
ます。
#include <stdio.h>
#include <stdlib.h>
void main(void) {
exit(0);
}
別のCファイルで、 ARMセミホスティングcommon.c
を使用して実装しexit
ます。
void _exit(int status) {
__asm__ __volatile__ ("mov r0, #0x18; ldr r1, =#0x20026; svc 0x00123456");
}
実装するその他の一般的なシステムコールは次のとおりです。
write
結果をホストに出力します。これは、次のいずれかで実行できます。
brk
のためにmalloc
。
ページングを気にする必要がないので、ベアメタルで簡単です!
TODO ZephyrやFreeRTOSのような本格的なRTOSに入らずに、プリエンプティブスケジューリングシステムコールの実行に到達するのは現実的かどうか疑問に思います。
Newlibの優れた点は、OS固有ではないものをすべてstring.h
実装し、OSスタブだけを実装できることです。
また、すべてのスタブを実装する必要はありませんが、必要なスタブだけを実装する必要があります。たとえば、プログラムにが必要なだけの場合exit
は、を指定する必要はありませんprint
。Newlibは、すべてのsyscallのダミーの何もしない実装を弱いシンボルとして与えることによってこれを実現します。
Newlibソースツリーには、の下にあるARMセミホスティング実装を含むいくつかの実装がすでにありnewlib/libc/sys/arm
ますが、ほとんどの場合、独自に実装する必要があります。ただし、タスクの強固な基盤を提供します。
Newlibをセットアップする最も簡単な方法は、crosstool-NGを使用して独自のコンパイラを構築することです。これは、NewlibをCライブラリとして使用することを指示するだけです。私のセットアップは、に存在するnewlib設定を使用するこのスクリプトcrosstool_ng_config
で自動的にそれを処理します。
C ++も理論的には機能するはずですが、私の最初の試みは失敗しました。