私が取り組んできた組み込みプロジェクトの副作用として、ARMプロセッサ用の小さなオペレーティングシステムを開発しました。OSとユーザーコードは別々のディレクトリにあり、それらの間に明確な境界があり、単一のMakefileを使用して単一のイメージに組み込まれます。
OSをオープンソースとしてリリースしたいのですが。これは、エクソカーネルとユーザーランドのドライバーライブラリで構成されています。
私が決定しようとしているのは、このOSのユーザーが、ビルド時に独自のコードと組み合わせて、フラッシュする単一のイメージを作成する方法です。私は3つの可能性を考えることができます:
1)ユーザーにプロジェクトの一部としてOSソースファイルを含めてもらいます。彼らは私が現在持っているセットアップを再作成するでしょう、そしてそれは例えばFreeRTOSがそれをするように見える方法です(それは3つのファイルしか持っていませんが)。
2)ユーザーコードがリンクできる.aファイルにOSをビルドさせます。これにより、ユーザーは独自のリンカースクリプトを使用してメモリの配置を完全に制御できます(また、テキスト、BSS、またはデータセクションの組み合わせがスペースを超えたときにリンカーがユーザーに通知できるようになります)。
3)OSに、ユーザーコードが最後に連結されることを期待する生のバイナリにビルドさせます。ユーザーコードは、メイン関数のアドレスを持つ小さなヘッダー(リンカースクリプトによって配置される)で始まります。ユーザーコードは、カーネルではなく、ユーザーランドドライバーのみの.aファイルにもリンクします。
(1)gitサブツリーと並行してOSとユーザーコードを開発するのが最も簡単になります。 (2)最も便利なリンクプロセスがあるようです。 (3)最大の分離を与えます。
あなたがそれを使っていたなら、あなたはどちらを好みますか、そしてなぜですか?
小規模システムのハードコア組み込みOSの場合、最初のオプションが唯一の実際に実行可能なオプションです。
問題は、ほぼすべてのチップセットで、ハードウェアとのインターフェイスを微調整する必要があり、新しいチップセット用にOSを再コンパイルする必要があるリスクが高いことです。
したがって、最初のオプションは、あなたにとって最も簡単であるだけでなく、次のプロジェクトに組み込むためにも最も簡単です。
最初にバートの答えに同意しますが、オプション(2+)について議論したいと思います。
OSSプロジェクトが成功し、OSを使用している開発者が数十人(または数百人)いて、V1でいくつかの重大な変更が加えられているV2での作業に忙しいと仮定します。一部のユーザーは、再現できない奇妙な問題を抱えています。これは、ビルド環境に関連していると思われます。突然、あなたはあなたのきれいな境界がそれほどきれいではないことに気づきます。
ソフトウェアコンポーネントとそれを使用するアプリケーションを考えると、2つが結合されるポイントは、ビルドプロセスのできるだけ遅い段階であることが非常に望ましいです。個別のコンパイルはインクルードファイルよりも優れており、リンク可能なライブラリはオブジェクトよりも優れており、ダイナミックライブラリは静的よりも優れており、ランタイムはコンパイル時間よりも優れています。 [明らかに、すべてのテクノロジーですべての選択肢が利用できるわけではありません。]
それはあなたが自由に使える技術に基づいたあなたの呼びかけですが、分離の側の誤りは時間の経過とともに利益をもたらすはずです。間隔が大きいほど良いです。