attributes, architecture, availability, CSI, stability, MT-Level, standard - インタフェースの属性
マニュアルページの「属性」セクションには、属性タイプと対応する値を定義する表が含まれます。属性表の例を次に示します。すべての属性タイプがすべての種類のインタフェースに適合するわけではありません。
|
アーキテクチャーはプロセッサまたは固有のハードウェアを定義します。uname(1) の –p オプションを参照してください。必要なアダプタまたは周辺機器を示す場合もあります。
これは、マニュアルページで説明されているコマンドまたはコンポーネントを含むソフトウェアパッケージを示します。このコマンドを使用できるようにするには、示されたパッケージがインストールされている必要があります。パッケージを追加する方法についての詳細は、pkg(1) を参照してください。
どのコードセットの特性にも依存していない OS ユーティリティーおよびライブラリは、コードセットの独立性 (CSI) を保持している、と言われます。これらは、CSI が有効な属性を持っています。これは、たとえば拡張 UNIX コードセット (EUC) でのみ動作するような、多くのコマンドやユーティリティーとは対照的です。EUC は、同時に 4 つまでのコードセットをサポートできるエンコーディング方式で、一般にアジア地域の文字セットを表すために使用されます。
ただし、実用上の理由によりこの独立性は絶対ではありません。現在の CSI 実装には、まだいくつかの仮定が適用されています。
ファイルコードは ASCII のスーパーセットです。
複数バイト文字および NULL で終わる UNIX ファイル名をサポートするため、NULL および / (スラッシュ) 文字を、複数バイト文字の一部に含めることはできません。
「ステートレス」ファイルコードのエンコーディングだけがサポートされています。ステートレスなエンコーディングでは、単一のシフトは除外されていませんが、シフト、ロッキングシフト、指示、呼び出しなどは避けられています。
プロセスコード (wchar_t 値) は実装に依存し、時期によって、または実装間やロケール間で、異なることがあります。
すべてのオブジェクトが、任意の文字で構成される名前を持つことができるわけではありません。次のオブジェクトは、ASCII 文字から構成される名前にする必要があります。
ユーザー名、グループ名、およびパスワード
システム名
プリンタおよび特殊デバイスの名前
端末の名前 (/dev/tty*)
プロセス ID 番号
メッセージキュー、セマフォー、および共有メモリーラベル。
以降は、ISO Latin-1 文字または EUC 文字で構成する必要があります。
ファイル名
ディレクトリ名
コマンド名
シェルの変数および環境変数名
ファイルシステムへのマウントポイント
NIS キー名およびドメイン名
NFS 共有ファイルの名前は、ASCII 文字で構成するようにしてください。ファイルやディレクトリの名前や内容に、ASCII 以外のコードセットの文字を使用することもできますが、ASCII コードセットのみを使用すると、ローカリゼーションに関係なくどのマシンでも NFS マウントを使用できます。CSI が有効になっているコマンドおよびユーティリティーはいずれも、2.6 でリリースされたシングルバイトおよび複数バイトのロケールを処理できます。アプリケーションが国際化サービスの完全なサポートを受けるには、動的結合を適用する必要があります。静的にリンクされたプログラムでは、C ロケールおよび POSIX ロケールだけがサポートされます。
Oracle Solaris は多くの場合、開発者が新しい技術をできるだけ早く評価できるようにするため、初期の段階で開発者がそれらの技術へアクセスできるようにします。残念ながら、新しい技術は変更が生じやすいため、標準化により以前のバージョンとのインタフェースの非互換性が生じることもよくあります。
リスクに対する予測を合理的に行うために、開発者は将来のリリースでインタフェースがどの程度変更される可能性があるかを知っておく必要があります。開発者がこうした予測をしやすくするため、インタフェースの安定性についての情報が、コマンド、エントリポイント、およびファイル形式に関するいくつかのマニュアルページに含まれています。
比較的安定したインタフェースについて、Oracle Solaris は、将来のマイナーリリースでも引き続き確実に動作するよう努力するため、ほぼすべてのアプリケーションで安全に使用できます。「確実」インタフェースにのみ依存するアプリケーションは、確実に将来のマイナーリリースでも正常に機能し続けます (ただし過去のメジャーリリースで機能するとは限らない)。
比較的安定していないインタフェースについては、実験と試作が可能ですが、将来のマイナーリリースで互換性のない変更がなされたり、削除されたり、代替のインタフェースと置き換えられたりする可能性を理解したうえで使用するようにしてください。
Oracle Solaris がドキュメント化しない「インタフェース」(たとえば、ほとんどのカーネルデータ構造やシステムヘッダーファイルの一部のシンボル) は、実装によるアーティファクトである場合があります。そのような内部インタフェースは、互換性のない変更がなされたり削除されたりする場合があり、また、通常、リリースノートでそのような変更について言及されることはありません。
リリースレベル互換性について検討する助けとして、製品には名前とともにリリースレベルが付与されています。各リリースレベルには、低いレベルに適合する変更も含まれます。
|
インタフェースの安定性に関しては、更新リリース (パッチリリースと呼ばれることもある) がマイクロリリースに相当すると見なされます。
分類次の表は、安定性レベルの分類とリリースレベルとの関係をまとめたものです。最初の列は安定性レベルです。2 番目の列は互換性のない変更のリリースレベルを、3 番目の列はその他のコメントを表します。個別の分類に関する完全な考察については、以降の該当するサブセクションを参照してください。
|
このマニュアルページで説明されているインタフェースの安定性レベルの分類は、特に明記しない限り、ソースインタフェースとバイナリインタフェースの両方に適用されます。すべての安定性レベルの分類は公開されていますが、非公開 (Private) 分類だけは例外です。公開インタフェース (マニュアルページにドキュメント化されたもの) の正確な安定性レベルは、明示されていない限り特定されていません。ドキュメント化されていないインタフェースの安定性レベルは、暗黙的に非公開です。
Oracle Solaris 製品のコンポーネントであるドキュメント以外のドキュメントが存在しても、Oracle Solaris 製品により提供されるインタフェースについて、いずれかの安定性レベルが暗示されているとみなすべきではありません。安定性レベルに関する唯一の情報源は、リファレンスマニュアルページです。
「確実」インタフェースの目的は、サードパーティーがこれらのインタフェースに基づいてアプリケーションを開発してリリースできるようにし、そのインタフェースが導入された製品のリリース以降、同じメジャーリリース内であればどのリリースでも、アプリケーションの動作を保証することです。メジャーリリースでも、互換性のない変更はまれにありますが、正当な理由を必要とします。
業界標準として定義され管理されているインタフェースは、多くの場合、「確実」インタフェースとして扱われます。この場合、管理している組織やバージョン管理された公開ドキュメントは、通常、ドキュメントの属性表やほかの部分で「標準」エントリに記述されています。
ごくまれなことですが、互換性のない変更が加えられる可能性もあります。このような変更は、このドキュメントの「例外」セクションで説明されているように重大な欠陥がある場合は任意のリリースで、また、サポート終了プロセスに従ったマイナーリリースで発生します。「確実」インタフェースのサポートを打ち切る必要がある場合、Oracle Solaris は通知を行うよう努め、安定性レベルが「廃止」としてマークされます。
このようなインタフェースについては、あるマイナーリリースから次のマイナーリリースへの移行で、ソースやバイナリの互換性は保証されません。インタフェースの削除といった互換性のない大幅な変更がマイナーリリースで加えられる可能性もあります。「不確実」インタフェースは、通常、リリースに依存しない製品での使用には適していません。
互換性のない変更をインタフェースに加える場合には、使いやすさの考慮なども含めて実際にインタフェースを向上させるという目的が必要です。一般的な想定として、「不確実」インタフェースに互換性のない変更が加えられる可能性は低く、そのような変更が発生してもその影響は小さく、多くの場合は軽減計画が存在します。
通常、「不確実」インタフェースは、次のいずれかのサブカテゴリに分類されます。
実験的または暫定的なインタフェース。通常、外部の開発者が新しいまたは急速に変化している技術を早く利用できるようにするため、あるいは、より一般的なソリューションが将来予期できる場合に、問題に対する暫定的なソリューションを提供するために使用されます。
外部組織によって仕様が管理されているインタフェース。Oracle Solaris は、外部仕様と同期をとれる次のマイナーリリースまで、以前のリリースとの互換性を保つために適切な努力をします。
安定性より革新性 (および使いやすさ) を重視するユーザーを対象としたインタフェース。この属性は、より高い層のコンポーネントの管理インタフェースに関連付けられることがよくあります。
「不確実」インタフェースの場合、Oracle Solaris は 2 つのマイナーリリース間でのソースまたはバイナリのどちらの互換性に関しても保証しません。これらのインタフェースに基づいて開発されるアプリケーションは、将来のマイナーリリースで動作しなくなる場合があります。
「流動的」インタフェースは、任意の理由でいつでも変更される可能性があります。
Oracle Solaris 製品では、「流動的」というインタフェースの安定性レベルを使用することで、急速に変化する流動的な仕様にすばやく追従できます。多くの場合、この方が利用者の期待に適切に応えることになるため、インタフェースの安定性の向上よりも優先されます。
通常、この分類レベルは、Oracle Solaris 以外の組織によって管理されているインタフェースに適用されます。ただし、標準化団体やフリーオープンソースソフトウェア (FOSS) コミュニティーによって管理されている、インタフェースの互換性を重視する仕様とは異なり、互換性のない変更がインタフェース仕様に加えられることは非常にまれであるとは断言できません。また、ユーザーに安定性を提供することよりも、最小限の遅延でコミュニティーに追従することの方が重要視される場合には、FOSS によって管理されているソフトウェアに適用されることもあります。
さらに、「流動的」という分類レベルは、信頼できる組織や広く認められている組織による定義の過程にあるインタフェースに適用されることもよくあります。これらはドラフト標準と総称されます。「IETF インターネットドラフト」は、よく理解されている開発中の仕様の例です。
「流動的」は、実験的なインタフェースにも適用できます。
「流動的」インタフェースの場合、パッチも含む 2 つのリリース間でのソースやバイナリの互換性は保証されません。このようなインタフェースを使用しているアプリケーションは、将来のリリースでは正しく機能しない可能性があります。
この状況は、インタフェースであると推測できるが実際にはインタフェースでないエンティティーが存在する場合に発生することがあります。一般的な例として、人による使用だけを目的とした CLI 出力や GUI の正確なレイアウトなどがあります。
このような混乱が発生しやすいと特定される状況では、この分類を使用して簡単に明確にすることができます。エンティティーにこの分類が適用されていないことは、そのエンティティーが何らかの形式のインタフェースであることを示すものではありません。混乱の可能性が特定されていないことだけを示しています。
非公開インタフェースは、提供元のコンポーネント (または製品) 自体による使用のみが意図されたインタフェースです。それでも非公開インタフェースは、ほかのコンポーネントから見えたりアクセスできたりする場合があります。ほかのコンポーネントの非公開インタフェースを使用することは安定性の大きなリスクが伴うため、そのような使用は明示的にサポートされていません。Oracle Solaris によって提供されていないコンポーネントは、非公開インタフェースを使用するべきではありません。
ほとんどの非公開インタフェースはドキュメント化されていません。非公開インタフェースがドキュメント化されているのは例外的です。非公開インタフェースがドキュメント化される理由として、公開安定性レベルのいずれかに再分類される予定がある、普及度が非常に高い、などが挙げられます。
「廃止」という修飾子は、前述の分類レベルとともに使用できます。「廃止」修飾子は、「非推奨」になった、または一般的な使用には推奨されなくなったインタフェースを示します。既存のインタフェースは、「廃止」修飾子の適用により、ほかのステータス (「確実」や「不確実」など) から降格されることがあります。これにより、そのインタフェースが削除される (または互換性のない変更が加えられる) 前に、そのインタフェースからの移行をユーザーに促します。
廃止インタフェースは現在のリリースではサポートされていますが、将来の (マイナー) リリースでは削除される予定です。インタフェースのサポートが中止されるとき、Oracle Solaris はサポートを中止する前に通知を行うよう努めます。廃止インタフェースを使用すると、警告メッセージが表示される場合があります。
まれに、インタフェースの安定性に関する保証を破棄することが Oracle Solaris とユーザーの両者にとって最大の利益になる場合があります。インタフェースの提供者がインタフェースの安定性に関する保証に違反する一般的な理由を、次の表にいくつか示します。
インタフェースに脆弱性が内在することによるセキュリティーホール。
インタフェースに脆弱性が内在することによるデータ破壊。
適合性テストの解釈の変更や強化によって明らかになる標準違反。
Oracle Solaris で管理されていないインタフェース仕様に互換性のない変更が加えられ、インタフェース利用者の大多数が新しいインタフェースを求めている。
互換性のない変更を行わないとユーザーの理解が得られない。たとえば、DOS 8.3 の命名規則の制限が廃止されたとき、pcfs に互換性のない変更が加えられました。
互換性のない変更が例外として認められる場合、変更は常に「できるだけ主要な」リリース手段で配布されます。ただし、脆弱性やブランド契約の要件のため、やむを得ずパッチで配布されることもあります。
以前のインタフェース分類方式との互換性Solaris 10 およびそれより前のリリースでは、異なるインタフェース分類方式が使用されていました。以前の分類方式と新しい分類方式のマッピングを次の表にまとめます。
|
フリーオープンソースソフトウェアの重要性が高まっているため、「安定」/「不安定」から「確実」/「不確実」という名前に変更されました。「安定」という用語は、FOSS コミュニティーでの一般的な使用法と競合していました。
「開発中」の定義があいまいなため、解釈が難しくなっていました。新しい分類方式への移行に伴い、以前の「開発中」インタフェースの多くが「確実」に昇格されました。ただし、「開発中」という用語が出現した場合は、「不確実」と見なすようにしてください。
ライブラリは、複数のスレッドをサポートする能力に応じてカテゴリに分類されます。複数または異なるレベルの関数を含むマニュアルページでは、「注意事項」または「使用法」のセクションでこの点が説明されています。
安全はマルチスレッドのアプリケーションから呼び出し可能なコードの属性です。安全インタフェースまたは安全コードセグメントへの呼び出しにより、複数のスレッドによって呼び出された場合でも結果が有効になります。よく見過ごされる点ですが、この安全インタフェースまたは安全コードセグメントの結果は、すべてのスレッドにグローバルな影響を及ぼす可能性があります。たとえば、あるスレッドのファイルを開いたり閉じたりするアクションは、プロセス内の他のすべてのスレッドから表示可能です。マルチスレッドのアプリケーションには、これらのインタフェースを安全な方法で使用する責任があり、これはインタフェースが安全かどうかとは異なります。たとえば、アプリケーション内の他のスレッドによってまだ使用中のファイルを閉じるマルチスレッドのアプリケーションは、close(2) インタフェースを安全に使用していません。
安全ではないライブラリには、保護されていないグローバルおよび静的なデータが含まれています。ライブラリ内で一度に 1 つのスレッドだけが実行されるようアプリケーションで取り決めない限り、このライブラリの使用は安全ではありません。安全ではないライブラリには安全な関数が含まれている場合がありますが、ほとんどのライブラリの関数は呼び出すのが安全ではありません。安全ではない一部の関数は、MT-安全である再入可能な対象を持ちます。再入可能な関数には、関数名に _r のサフィックスが付いています。
MT-安全ライブラリは、マルチスレッドのアクセスに対する準備が整っています。ロックによってグローバルおよび静的なデータを保護し、適度な量の並行性を実現しています。安全に使用できるライブラリも、MT-安全であるとは限りません。たとえば、ライブラリ全体をモニターで囲むとライブラリは安全になりますが、並行性をサポートしないため MT-安全とはみなされません。MT-安全ライブラリは適度な量の並行性を許容する必要があります。(この定義の目的は、ライブラリが安全であるとされる際に、その意味するものを明確にすることです。安全なライブラリの定義では、ライブラリが並行性をサポートするかどうかは示しません。MT-安全の定義では、ライブラリが安全で、ある程度の並行性をサポートすることを明確にしています。つまり安全の定義では、シングルスレッドを意味する場合も、任意の程度のマルチスレッドを意味する場合もあります。)
非同期シグナル安全とは、シグナルハンドラから安全に呼び出すことのできる特定のライブラリ関数のことです。非同期シグナル安全関数を実行するスレッドは、シグナルによって割り込まれた場合に、自分自身でデッドロックすることはありません。シグナルは、ロックを取得する MT-安全関数にとってのみ問題になります。
非同期シグナル安全関数は、MT-安全でもあります。非同期シグナル安全関数でロックが取得されると、シグナルは無効になります。これらのシグナルは、同じロックを取得する可能性のあるシグナルハンドラが呼び出されないようにします。
例外の説明については、このページの「注意事項」または 「使用法」のセクションを参照してください。
例外の説明については、このページの「注意事項」または 「使用法」のセクションを参照してください。
fork(2) 関数は、その関数を呼び出したスレッドだけを子プロセスに複製します。fork1(2) 関数は、以前の関数との互換性のために存在しており、 fork() と同義です。fork() が呼び出されたとき、fork を実行しているスレッド以外のスレッドがロックを保持していた場合、ロックは子プロセスに引き続き保持されますが、所有者であるスレッドは複製されないため、ロックには所有者がいないことになります。ロックの取得を試みる関数を子が呼び出すと、デッドロックが発生します。
fork() が呼び出されるとき、Fork-安全ライブラリはその内部ロックすべてが fork を実行するスレッドによってのみ保持されるようにします。これは通常、ライブラリの初期化時に呼び出される pthread_atfork(3C) により実現されます。
forkall(2) 関数は、まれなケースとして、fork を実行するときにプロセスがそのすべてのスレッドを複製する必要がある場合にその機能を提供します。forkall() が呼び出されたときに、pthread_atfork() アクションは実行されません。forkall() を呼び出すことに関連する危険が存在します。プロセス内のスレッドで入出力操作を実行中に、別のスレッドが forkall() を呼び出すと、同じ入出力操作が親プロセスと子プロセスの両方で行われ続け、結果としてデータが破壊される場合があります。このような競合状態に関する理由から、forkall() の使用は推奨されていません。
Solaris 10 よりも前のすべての Solaris リリースでは、fork() の動作はアプリケーションが –lpthread (POSIX スレッド、standards(5) を参照) とリンクしているかどうかに依存していました。–lpthread とリンクされている場合、fork() は fork1() と同じように動作し、リンクしていない場合は forkall() と同じように動作していました。fork() の動作に関する混乱を避けるため、アプリケーションは状況に応じてfork1() または forkall() を指定できるようになりました。
マルチスレッドアプリケーションが pthread_cancel(3C) を使用してスレッドを取り消し (すなわち終了) する場合、対象となるスレッドがロックまたは割り当てられたメモリーなどのリソースを保持したまま終了する場合があります。スレッドにリソースを適切に解放する適切な取り消しクリーンアップハンドラがインストールされていない場合 (pthread_cancel(3C) を参照)、アプリケーションは「取り消し非安全」つまり取り消しに関して安全ではないことになります。このように安全でないと、取り消されたスレッドのロックが解放されないため、またはリソースリーク (たとえばスレッドの取り消し時にメモリーが解放されないなど) のために、デッドロックが生じる可能性があります。pthread_cancel(3C) を使用するアプリケーションはすべて、取り消し安全環境で実行されるべきです。取り消しポイントを持ち、ロックなどのリソースを取得したり動的にメモリーを割り当てたりするライブラリは、これらのライブラリにリンクされたアプリケーションの取り消し非安全性の一因となります。これにより、マルチスレッドプログラムでのライブラリの安全性に別のレベルが導入されることになります。 取り消し安全性です。取り消し安全性には、2 つのサブカテゴリがあります。 遅延取り消し安全性、および非同期取り消し安全性です。取り消しのタイプが PTHREAD_CANCEL_DEFERRED であるスレッドが取り消し安全であるとき、アプリケーションは遅延取り消し安全であるとみなされます。取り消しのタイプが PTHREAD_CANCEL_ASYNCHRONOUS であるスレッドが、取り消し安全であるとき、アプリケーションは非同期取り消し安全であるとみなされます。非同期取り消しタイプはどこでも取り消しができる一方、遅延取り消しタイプのスレッドは十分に定義された取り消しポイントによってのみ取り消しができるため、非同期取り消し安全性よりも遅延取り消し安全性の方が目的を達成するのが容易です。すべてのスレッドはデフォルトで遅延取り消しタイプを含んで作成されるため、非同期の取り消しを安全に行うことを心配する必要はないかもしれません。ほとんどのアプリケーションおよびライブラリは、常に非同期取り消し非安全であるものと想定されています。非同期取り消し安全であるアプリケーションは、定義上は、遅延取り消し安全でもあります。
多くのインタフェースが業界標準として定義され管理されています。これに該当する場合、管理している組織やバージョン管理された公開ドキュメントは、このセクションに記述されています。
移植性のあるアプリケーションを作成するプログラマは、公的標準に基づくインタフェースのマニュアルページの説明ではなく、アプリケーションが準拠しようとする標準または仕様に存在するインタフェースの説明を利用するべきです。標準または仕様に代替の実装の選択肢がある場合、通常、マニュアルページには Oracle Solaris による代替の実装だけが説明されています。マニュアルページでは、Oracle Solaris が提供する標準インタフェースの基本定義に対する互換性のある拡張についても説明されています。
管理している組織やドキュメントが「標準」エントリとして引用されている場合でも、承認されているとは見なさないでください。管理している組織には、ISO や ANSII のように非常に公的な組織もあれば、それほど公式ではないが一般に認められている IETF などの組織や、FOSS (フリーオープンソースソフトウェア) の単独貢献者のように非公式なものもあります。