システムプログラミングは何ですか？
4770 ワード
一部は『Linux System Prograamming』の作者：Robert Love劉建文略訳から抜粋しました。http://blog.csdn.net/keminlau)
System Program ming
過去のUnixプログラミングにはシステム不全はありませんでした。
X Windowを開発してもシステムレベルでプログラミングして、システムのすべてのAPIを見ます。近代的なオペレーティングシステムのプログラミングには、いわゆる「システムクラスプログラミング」があります。「アプリケーションプログラミング」とは異なるAPIを使います。
プログラミングの形式と労力の消耗から。システムプログラミングとアプリケーションプログラムの本質的な違いはありません。これは経験豊富なアプリケーションを意味します。
システムプログラミングとアプリケーションプログラミングの違いは、第一に、システムプログラミングはハードウェアに近いです。システムプログラム猿はハードウェア環境とオペレーティングシステム環境を熟知しなければならない。それに対して、アプリケーション猿の多くは他のアプリケーションに詳しい環境です。 第二に、システムプログラミングで使用される関数ライブラリおよびライブラリ関数呼び出し方法は、アプリケーションプログラミングとは若干異なる。例えば、システムコールを呼び出すときに、いわゆる割り込み方式、つまりソフト中断方式を使う。近年、計算応用が深化するにつれて、アプリケーションプログラミングはシステムプログラミングから遠い傾向がある。 ただ、これはシステムプログラミングの最後の日が来るとは言えません。なぜなら、JavascriptやC葃を使ってアプリケーションを書く人がいるからです。
また、オペレーティングシステムコードは、システムレベルのプログラミングのみを使用することができます。
本の核心問題：
システムレベルインターフェース（system-level interface）は一体何ですか？どのようにLinuxのシステムレベルのアプリケーションを作成しますか？カーネルとCライブラリは詳しく何を提供してくれましたか？良いコードはどう書きますか？Linuxはまたどんな公知の落とし穴がありますか？Linuxのシステムコールはどうやって実現されますか？What neat system cals are provided in Linux compred to other Unix variants？How does it all work？Those questions art theセンターof this book.
Linuxシステムのプログラミングには、3つの大きな内容を熟知する必要があります。システムの呼び出し、Cライブラリ、Cコンパイラ。
System Calls
[システム呼び出し]とは、ユーザ空間とカーネルとの間の関数インターフェースであり、ユーザ空間のプログラムにカーネルサービスとリソースを要求することを目的とする。他の非常に多くのオペレーティングシステムと比較します。Linuxで実現されるシステムの呼び出しは非常に少ない。例えば、LinuxはI 386システムで300ぐらいのシステム呼び出しを実現しました。Microsoft Windowsは、何千というシステムの呼び出しを実現しているという。
Linuxカーネルの異なるプラットフォームは現在システムの呼び出しに違いがあります。90%のシステムの呼び出しは同じです。
Invoking system cals
セキュリティなどの理由で、アプリケーションコードは直接システムを呼び出すことができません。特殊な「罠」（trop）機構を使用しなければならない。「知会」のカーネルで動作する関数呼び出しの形式（KEMIN：両「システム」の結合度が弱いことを証明しています。直接呼び出しの方式より弱いです。システム論の角度からsysscallを追究するのもとても面白いです。）システムの詳細な実装は、システムによって異なります。
例えば、I 386システムでは、アプリケーションコードは、ソフト中断命令（int 0 x 80）をトリガすることにより、sysscallを呼び出す。じゃ0 x 80は何ですか？ソフトウェアはベクトル番号を中断しますか？答えますか
アプリケーションコードは、プロセッサのレジスタを介してカーネルベクトル番号と呼び出しパラメータに通知しなければならない。たとえ。アプリケーションコードがopen()を呼び出すと、eax値5をセットして、別の5つのレジスタ：ebx、ecx、edx、esi、およびedi(したがって、システム呼び出しは最大5つのパラメータを使用して)、これらのレジスタは実ユーザ空間のアドレス、つまりパラメータデータを保存します。
システムプログラム猿としては、システムによって定義される呼び出しプロセスに干渉する必要はありません。そしてCライブラリとCコンパイラが自分で進んで処理します。
The C Library
CライブラリはUNXアプリケーションのすべてのコアである。あなたがどんな言語を使っても、コードはついにCライブラリを呼び出します。他の高級言語のライブラリはCライブラリに基づいて構築されています。あるいはこれらのライブラリはCライブラリに対する包装です。
今のLinuxで使われているCライブラリはGNU libcです。行話glibc
glibcはプログラム言語ライブラリに過ぎません。例えばC標準ライブラリです。まだシステムライブラリであり、近代的なオペレーティングシステムライブラリであり、システムに対して呼び出された包装、スレッドサポート、ネットワークサポートなどをカバーしています。
The C Compler
LinuxのCコンパイラはgccで、過去gccはGNU C Copilerを代表しています。ccのGNUプロジェクトの実現です。今gccはGNU Copiler Collectionを代表していますが、gccだけはまだCコンパイラの入口です。
Unixシステム（Linuxを含む）で使用されるコンパイラは、システムプログラミングに高度に関連しています。コンパイラが担当していますので、C規格とシステムABIを実現しました。
API and ABIs
自分で書いたプログラムがとても良い移植性を持つことを望まない人はいません。異なるソフトウェアプラットフォーム（例えば、オペレーティングシステムまたはアプリケーションフレームワーク）、プロセッサシステムおよびキャリアボードなどのハードウェアプラットフォーム、さらにはプラットフォームの開発バージョン番号にまたがって実行することができる。
様々な要因がプログラムの移植性に影響を与えています。その中には、2つの異なるグループの「システムインターフェース」がプログラムの移植可能性に影響を与えます。1つ目はアプリケーションプログラミングインターフェース（API）、もう1つはアプリケーションバイナリインターフェース（ABI）です。
API
APIは2つのソフトウェアのソースレベルのインターフェイスです。この標準的なインターフェース（一般的に関数として実装される）により、クライアントコード（一般的には高レベルのソフトウェアコード）は、サービスコード（低レベルのソフトウェアコード）を呼び出すことができます。API自体は抽象的で、一つのインターフェースだけを定義しています。アプリケーションがどのように実現されるかに関わらない細部。
APIはソースレベルのインターフェースであり、論理的な約束である。ABIはバイナリレベルインターフェースであり、特定のアーキテクチャ上の2つのソフトウェアモジュール間のインターフェースを定義する物理的なインプリメンテーション方式である。このような「物理的実現の約束」はバイナリコードの互換性を保証します。つまり、一定の目標コードは何でも同じABIシステムで正常に動作します。またソースをコンパイルする必要がありません。
ABI（「物理的実現の約束」）の内容は、呼び出しの約束（calling conventions）、バイトの順序（byte ordeng）、レジスタの使用（register use）、システム呼び出しの実施形態、オブジェクトのリンク、ライブラリの挙動、およびバイナリフォーマットを含む。規則の呼び出しを例にとって、関数がどのように呼び出されるかを規定しています。どのようにパラメータが伝達され、どのようなレジスタが保留されていますか？
以前は、特定のアーキテクチャの異なるオペレーティングシステム（特にi 386上のUnixオペレーティングシステム）のために一意のABIを定義することを試みたが、これまでは効果が得られていない。逆に、Linuxを含むオペレーティングシステムはそれぞれ独立したABIを定義しようと試みています。これらのABIは構造と密接につながっています。
ABIのほとんどは、特定のレジスタやアセンブリ命令などのマシンレベルの概念に関連しています。
したがって。Linuxシステムにあります。各マシンアーキテクチャは自分のABI集合を持っています。実は、これらのABIをマシンアーキテクチャの名前で呼んでいます。たとえば、アルファx 86-64などです。
1.4 Linuxプログラミング概念、POSIXとシステムライブラリ
すべてのUnixシステムは、Linuxシステムを含みます。共通の抽象的およびインターフェース集合を提供しており、この共通点はUnixを定義している。
ファイルとプロセスの抽象、パイプとソケット管理のインターフェースなど、Unixの核心的な内容です。
以上のように、個人的には、システムプログラミングとアプリケーションプログラムの違いは、呼び出しのインターフェースが異なることを理解しています。
System Program ming
過去のUnixプログラミングにはシステム不全はありませんでした。
X Windowを開発してもシステムレベルでプログラミングして、システムのすべてのAPIを見ます。近代的なオペレーティングシステムのプログラミングには、いわゆる「システムクラスプログラミング」があります。「アプリケーションプログラミング」とは異なるAPIを使います。
プログラミングの形式と労力の消耗から。システムプログラミングとアプリケーションプログラムの本質的な違いはありません。これは経験豊富なアプリケーションを意味します。
システムプログラミングとアプリケーションプログラミングの違いは、
また、オペレーティングシステムコードは、システムレベルのプログラミングのみを使用することができます。
本の核心問題：
システムレベルインターフェース（system-level interface）は一体何ですか？どのようにLinuxのシステムレベルのアプリケーションを作成しますか？カーネルとCライブラリは詳しく何を提供してくれましたか？良いコードはどう書きますか？Linuxはまたどんな公知の落とし穴がありますか？Linuxのシステムコールはどうやって実現されますか？What neat system cals are provided in Linux compred to other Unix variants？How does it all work？Those questions art theセンターof this book.
Linuxシステムのプログラミングには、3つの大きな内容を熟知する必要があります。システムの呼び出し、Cライブラリ、Cコンパイラ。
System Calls
[システム呼び出し]とは、ユーザ空間とカーネルとの間の関数インターフェースであり、ユーザ空間のプログラムにカーネルサービスとリソースを要求することを目的とする。他の非常に多くのオペレーティングシステムと比較します。Linuxで実現されるシステムの呼び出しは非常に少ない。例えば、LinuxはI 386システムで300ぐらいのシステム呼び出しを実現しました。Microsoft Windowsは、何千というシステムの呼び出しを実現しているという。
Linuxカーネルの異なるプラットフォームは現在システムの呼び出しに違いがあります。90%のシステムの呼び出しは同じです。
Invoking system cals
セキュリティなどの理由で、アプリケーションコードは直接システムを呼び出すことができません。特殊な「罠」（trop）機構を使用しなければならない。「知会」のカーネルで動作する関数呼び出しの形式（KEMIN：両「システム」の結合度が弱いことを証明しています。直接呼び出しの方式より弱いです。システム論の角度からsysscallを追究するのもとても面白いです。）システムの詳細な実装は、システムによって異なります。
例えば、I 386システムでは、アプリケーションコードは、ソフト中断命令（int 0 x 80）をトリガすることにより、sysscallを呼び出す。じゃ0 x 80は何ですか？ソフトウェアはベクトル番号を中断しますか？答えますか
アプリケーションコードは、プロセッサのレジスタを介してカーネルベクトル番号と呼び出しパラメータに通知しなければならない。たとえ。アプリケーションコードがopen()を呼び出すと、eax値5をセットして、別の5つのレジスタ：ebx、ecx、edx、esi、およびedi(したがって、システム呼び出しは最大5つのパラメータを使用して)、これらのレジスタは実ユーザ空間のアドレス、つまりパラメータデータを保存します。
システムプログラム猿としては、システムによって定義される呼び出しプロセスに干渉する必要はありません。そしてCライブラリとCコンパイラが自分で進んで処理します。
The C Library
CライブラリはUNXアプリケーションのすべてのコアである。あなたがどんな言語を使っても、コードはついにCライブラリを呼び出します。他の高級言語のライブラリはCライブラリに基づいて構築されています。あるいはこれらのライブラリはCライブラリに対する包装です。
今のLinuxで使われているCライブラリはGNU libcです。行話glibc
glibcはプログラム言語ライブラリに過ぎません。例えばC標準ライブラリです。まだシステムライブラリであり、近代的なオペレーティングシステムライブラリであり、システムに対して呼び出された包装、スレッドサポート、ネットワークサポートなどをカバーしています。
The C Compler
LinuxのCコンパイラはgccで、過去gccはGNU C Copilerを代表しています。ccのGNUプロジェクトの実現です。今gccはGNU Copiler Collectionを代表していますが、gccだけはまだCコンパイラの入口です。
Unixシステム（Linuxを含む）で使用されるコンパイラは、システムプログラミングに高度に関連しています。コンパイラが担当していますので、C規格とシステムABIを実現しました。
API and ABIs
自分で書いたプログラムがとても良い移植性を持つことを望まない人はいません。異なるソフトウェアプラットフォーム（例えば、オペレーティングシステムまたはアプリケーションフレームワーク）、プロセッサシステムおよびキャリアボードなどのハードウェアプラットフォーム、さらにはプラットフォームの開発バージョン番号にまたがって実行することができる。
様々な要因がプログラムの移植性に影響を与えています。その中には、2つの異なるグループの「システムインターフェース」がプログラムの移植可能性に影響を与えます。1つ目はアプリケーションプログラミングインターフェース（API）、もう1つはアプリケーションバイナリインターフェース（ABI）です。
API
APIは2つのソフトウェアのソースレベルのインターフェイスです。この標準的なインターフェース（一般的に関数として実装される）により、クライアントコード（一般的には高レベルのソフトウェアコード）は、サービスコード（低レベルのソフトウェアコード）を呼び出すことができます。API自体は抽象的で、一つのインターフェースだけを定義しています。アプリケーションがどのように実現されるかに関わらない細部。
port [ ] ， 。 。 。
。 。
， 。 。 ， ， 。
API ？ 。 C ， 。 ； POSIX ， 。
APIはソースレベルのインターフェースであり、論理的な約束である。ABIはバイナリレベルインターフェースであり、特定のアーキテクチャ上の2つのソフトウェアモジュール間のインターフェースを定義する物理的なインプリメンテーション方式である。このような「物理的実現の約束」はバイナリコードの互換性を保証します。つまり、一定の目標コードは何でも同じABIシステムで正常に動作します。またソースをコンパイルする必要がありません。
ABI（「物理的実現の約束」）の内容は、呼び出しの約束（calling conventions）、バイトの順序（byte ordeng）、レジスタの使用（register use）、システム呼び出しの実施形態、オブジェクトのリンク、ライブラリの挙動、およびバイナリフォーマットを含む。規則の呼び出しを例にとって、関数がどのように呼び出されるかを規定しています。どのようにパラメータが伝達され、どのようなレジスタが保留されていますか？
以前は、特定のアーキテクチャの異なるオペレーティングシステム（特にi 386上のUnixオペレーティングシステム）のために一意のABIを定義することを試みたが、これまでは効果が得られていない。逆に、Linuxを含むオペレーティングシステムはそれぞれ独立したABIを定義しようと試みています。これらのABIは構造と密接につながっています。
ABIのほとんどは、特定のレジスタやアセンブリ命令などのマシンレベルの概念に関連しています。
したがって。Linuxシステムにあります。各マシンアーキテクチャは自分のABI集合を持っています。実は、これらのABIをマシンアーキテクチャの名前で呼んでいます。たとえば、アルファx 86-64などです。
1.4 Linuxプログラミング概念、POSIXとシステムライブラリ
すべてのUnixシステムは、Linuxシステムを含みます。共通の抽象的およびインターフェース集合を提供しており、この共通点はUnixを定義している。
ファイルとプロセスの抽象、パイプとソケット管理のインターフェースなど、Unixの核心的な内容です。
以上のように、個人的には、システムプログラミングとアプリケーションプログラムの違いは、呼び出しのインターフェースが異なることを理解しています。