test

システムインタフェース

第 1 章 API の概要

Sun の目標の 1 つに、Solaris の Architectual Interfaces を明確にするということがあります。これには次の 2 つの理由があります。

プログラミングインタフェース

Solaris は、プログラミングインタフェース、ユーザインタフェースの各要素、プロトコル、ファイルシステム内のオブジェクトの命名規則や位置など、さまざまな「インタフェース」を提供しています。システムにとって最も重要なインタフェースの 1 つが、開発者に提供するプログラミングインタフェースです。プログラミングインタフェースは、次の 2 つの部分に分かれています。1 つは、アプリケーション開発者に関係する部分で、API (アプリケーションプログラミングインタフェース) と呼ばれます。もう 1 つは、デバイスドライバやプラットフォームサポートモジュールのようにシステムコンポーネントの開発者に関係するもので、SPI (システムプログラミングインタフェース) と呼ばれます。

開発者は Solaris の各プログラミングインタフェースを、ソースレベルとバイナリレベルという 2 つのレベルで「見る」ことができます。API や SPI という頭字語を使用する場合は、システムのソースレベルのプログラミングインタフェースを示します。アプリケーションバイナリインタフェース (ABI)、システムバイナリインタフェース (SBI) という用語を使用して、それぞれのソースレベルのプログラミングインタフェースに対応するバイナリインタフェースを示します (「ABI」という用語は他のバイナリインタフェースと混同しがちなので、「Solaris ABI」という用語のみを使用します)。

インタフェース関数

このマニュアルで説明する SunOS 5 の関数は、カーネルとアプリケーションプログラムから提供されるサービス間のインタフェースです。Solaris 7 Reference Collection の 『man Pages(2): System Calls』 および 『man Pages(3): Library Routines』 に掲載されている関数は、SunOS 5 オペレーティングシステムとのアプリケーションのインタフェースです。これらの関数により、アプリケーションでファイルシステム、プロセス間通信のプリミティブ、マルチタスク機構などの機能を使用できます。この『システムインタフェース』は、API の重要部分を説明するマニュアルセットの中の 1 つです。その他に、このセットには『STREAMS Programming Guide』、『マルチスレッドのプログラミング』、『Transport Interfaces Programming Guide』などのマニュアルが含まれています。

Solaris 7 Reference Collection の 『man Pages(2): System Calls』と 『man Pages(3): Library Routines』 に掲載されているライブラリルーチンを使用すると、プログラム作成時はその実装の詳細を意識する必要がなくなります。たとえば、標準 C ライブラリ内の fread 関数は read をベースに実装されています。

C プログラムは、プログラムのコンパイル時に呼び出す関数に自動的にリンクされます。この手順は、他の言語で作成されたプログラムで異なることがあります。詳細は、『リンカーとライブラリ』を参照してください。

ライブラリ

Solaris は、静的バージョンと動的バージョンのライブラリを提供しています。静的ライブラリはインタフェースを提供せず、関数の実装だけを提供します。開発者は、共用ライブラリ (共用オブジェクトともいいます) を通じて、Solaris のアプリケーションプログラミングインタフェースを利用できます。実行環境では、動的にリンクされた実行可能オブジェクトと共用オブジェクトが実行時リンカによって処理され、実行可能プロセスが生成されます。システムとの公開 API は、アプリケーションと動的共用ライブラリ間のインタフェースです。

静的ライブラリ

ライブラリ (.a ファイルまたはアーカイブ) の従来の静的実装では、アプリケーションプログラミングインタフェースはその実装 (ライブラリの内容) に依存しています。アプリケーションを静的ライブラリにリンクすると、そのライブラリを実装するオブジェクトコードは構築された実行可能オブジェクトに組み込まれます。ライブラリとのソースレベルのプログラミングインタフェースを保持することもできますが、将来リリースされるオペレーティングシステムの新バージョンで動作する実行可能オブジェクトを生成するには、アプリケーションをリンクし直さなければなりません。将来のバイナリ互換性は、共用ライブラリを使用する場合にのみ保証されます。

静的ライブラリは歴史的な経緯があって残されているため、その実装から独立した形でインタフェースを定義するメカニズムはありません。このため、新しいアプリケーションでは静的ライブラリを使用しないようにしてください。

動的ライブラリ

静的ライブラリと違って、共用ライブラリではアプリケーションプログラミングインタフェースが実装に依存しません。インタフェースは、実行時にのみライブラリの実装にバインドされます。このため、Sun は API を管理し、それに対して構築されたアプリケーションとのバイナリ互換性を保ちつつ、内部インタフェースの変更など、ライブラリの実装を進めることができます。

インタフェースの分類

インタフェースは、そのインタフェースの使用者や使用方法によって次のように分類されて定義されます。

公開仕様 

Sun が公開するインタフェース仕様で、顧客は無償で使用 (Sun によるインタフェースの実装を使用する製品を構築) できる。顧客以外は代替実装を自由に提供でき、ライセンスや法的制限は適用されない 

非公開仕様 

Sun が公開しないインタフェース仕様。Sun は、このインタフェース仕様に基づいて顧客が製品を構築したり、顧客以外が代替実装を構築することを望んでいない 

互換性のある変更 

インタフェースやその実装に対して、それまでの有効なプログラムに影響しない方法で行う変更 

互換性のない変更 

インタフェースの変更や、その実装に対して、それまでの有効なプログラムが無効になるような方法で行う変更。これには、バグの修正や性能の低下が含まれる。定義されていない「実装の成果」に依存するプログラムは含まない 

標準クラス

仕様 

公開  

互換性のない変更 

メジャーなリリース番号 (X.0)  

例 

POSIX、ANSI-C、Solaris ABI、SCD、SVID、XPG、X11、DKI、VMEbus、Ethernet 

標準インタフェースとは、Sun 以外のグループによって仕様が管理されているインタフェースのことです。これには、POSIX、ANSI C などの規格や、X/Open、MIT X コンソーシアム、OMG などのグループによる業界仕様が含まれます。

公開クラス

仕様 

公開  

互換性のない変更 

メジャーなリリース番号 (X.0)  

例 

Sun DDI、XViewTM、ToolTalkTM、NFSTM プロトコル、Sbus、OBP

上記のインタフェースの仕様は、Sun が全面的に管理しています。これらのインタフェースの仕様書も公開していて、互換性を保つことを確約しています。

破棄されたクラス

仕様 

なし  

互換性のない変更 

マイナーなリリース番号 (X.0)  

例 

RFS 

一般に使用されなくなったインタフェースです。使用形態の変更を顧客に伝えるために、標準の移行用プログラムによって既存のインタフェースを他の状態 (公開や標準など) から「破棄」に格下げすることがあります。

使用形態を変更するには、インタフェースの差し替え意図を 1 年前から各顧客と Sun 製品開発コミュニティに通知する必要があります。現状のインタフェースと互換性のない変更を含む製品を出荷するまでに、1 年が経過しなければなりません。

顧客への通知手段には、サポート契約、リリースノートまたは製品マニュアルに関する問い合わせ、問題のインタフェースに該当する顧客フォーラムへの発表などが含まれます。

差し替え通知は、顧客が自由に入手できる「公開」情報と見なされます。プレス発表や類似の広報など、特定の処置によって情報を「公開」する予定はありません。