このコースでは、モバイルオペレーティングシステムインターフェイス（POSIX）の標準と、この標準に基づいてアプリケーションをプログラミングするための手法と方法を、多数の例で説明します。 マルチプロセスシステムのプログラミング、分散構成のフレームワーク内でのアプリケーションの相互作用の問題に触れます。 モビリティの提供（携帯性、携帯性） ソフトウェア（PO）は、非常に重要で複雑なタスクです。 今日、この状況は大規模な正当化を必要とすることはほとんどありません。ソフトウェアのモビリティを向上させるために一般的に受け入れられている方法の1つは、アプリケーション環境を標準化することです。 システムサービスのレベルでは、このような環境はPOSIX標準（ポータブルオペレーティングシステムインターフェイス）で記述されています。 この名前は、有名なスペシャリストであり、フリーソフトウェアファウンデーションの創設者であるリチャードストールマンによって提案されました。

このコースでは、2003年版の最新バージョンを検証します。これは、「トリプル標準」と呼ぶことができます。つまり、IEEE Std 1003.1標準、Open Group技術標準、そして最も重要なのは、国際ISO / IEC9945です。このコースの標準は、標準化されたユーティリティと関数を使用する手法と方法を理解することです。 目標は、OS実装のすべての微妙な点、考えられるすべてのエラーコードなどを強調して、標準を再説明することではありませんでした。 私たちの意見では、主なことは、標準の精神を感じ、それに固有の可能性をモバイルで使用することを学ぶことです。 読者がCに堪能であると仮定すると、その構文または教科書ライブラリ関数のいずれも考慮していません。 標準のコマンド言語とそのインタープリターについては、このトピックの概要がある程度詳しく説明されていますが、多くの実践的なプログラマーは他のインタープリターを使用することを好みます。 プログラムの例には、量と役割の両方の点で重要な場所が示されています。 標準の多くの規定（たとえば、エラー状況の処理に関連する）は、本文ではなく、対応する例に記載されています。後者は、可能な場合は常に、いくつかのハードウェアおよびソフトウェアプラットフォームでコンパイルおよび実行されました。 POSIX標準に準拠していると主張する学位または別の人。 ただし、見落としは確かに可能です。 コース全体と個々のプログラムの例の両方に関連するすべてのコメントと提案に感謝します。

POSIX標準の作成の歴史と現在の状況。

ソフトウェア（SW）のモビリティ（移植性、移植性）を確保することは、非常に重要で複雑な作業です。 私たちの時代では、この状況は大規模な正当化をほとんど必要としません。 ソフトウェアの移植性を高めるために一般的に受け入れられている方法の1つは、アプリケーション環境を標準化することです。提供されているAPI、ユーティリティなどです。 システムサービスのレベルでは、このような環境はPOSIX標準（ポータブルオペレーティングシステムインターフェイス）で記述されています。 この名前は、有名な専門家であり、フリーソフトウェアファウンデーションの創設者であるリチャードストールマンによって提案されました。

タイトルページ。
出力。
講義1.POSIX標準の基本的な概念とアイデア。
講義2.シェル言語。
講義3.「ユーザー」の概念を提供するユーティリティと機能。
講義4.ファイルシステムの構成。
講義5.ファイルの入出力。
講義6.構造化データを処理するためのツール。
講義7.プロセス。
講義8。プロセス間通信の手段。
講義9.共通端末インターフェース。
講義10.ホストの特性の調査とアプリケーションでのそれらの使用。
講義11.ネットワーク設備。
講義12.時間と彼と一緒に働きます。
講義13。言語的および文化的環境。
講義14.結論。
参考文献。

無料ダウンロード 電子書籍便利な形式で、以下を見て読んでください。
書籍Programmingin the POSIX standard、part 1、Galatenko V.A.、2016-fileskachat.comを高速かつ無料でダウンロードしてください。

POSIXおよびRVOS：体系化の試み

セルゲイ・ゾロタレフ、ニコライ・ゴルブノフ

この記事の目的は、リアルタイムオペレーティングシステム（RT OS）に適用されるPOSIX標準の開発の歴史を明確にすることです。

はじめに：プログラミングインターフェイスの標準化が必要なのはなぜですか？

POSIX標準の最も重要な機能の1つは、複雑なソフトウェアおよびハードウェアシステムの開発者が従わなければならない「標準化されたプログラミングインターフェイス」を定義することです。 これらのシステムの作成者は、市場投入までの時間の短縮（競争の激化による）、コストの最小化、投資収益率の向上などの要件に直面することを余儀なくされています。 同時に、開発プロセスの減速によるコストの大部分は、プログラマーが長い間利用可能であった機能を何度も何度も実装し、「車輪の再発明」をしなければならないという事実に関連しています。 しかし、これは次の方法で回避できた可能性があります。

• 過去および並行プロジェクトからのコードの再利用。
• 他のオペレーティングシステムからのコードの移植。
• 他のプロジェクトから開発者を引き付ける（他のオペレーティングシステムの使用を含む）。

これはすべて、標準化されたAPIを備えたOSを使用することで可能になります。 さらに、最初のケースで組織が特定の内部標準（特にプロプライエタリオペレーティングシステムで一般的）を持つだけで十分な場合、次の2つのケースでは、一般に受け入れられている標準（POSIXなど）の存在が必要です。

したがって、POSIX互換OSをプロジェクトのプラットフォームとして使用すると、開発者は、過去または並行プロジェクトとサードパーティのプロジェクトの両方から、完成したコードをソーステキストレベルで転送する機会を得ることができます。 これにより、ソフトウェア開発時間が大幅に短縮されるだけでなく、テストされたコードに含まれるエラーが常に少なくなるため、品質も向上します。

POSIX開発のWho'sWho

そして、POSIX標準自体から始めるのではなく、その作業に関与する組織の役割の順序から始めます。

最初の参加者は IEEE（電気電子学会、電気電子技術者協会）、専門家の公的非営利団体。 IEEEは1884年（正式には1963年から）にさかのぼり、150か国からの380,000人の個々のメンバーを統合し、コンピューター、制御、電気および情報技術の使用に関連する技術文献の3番目の部分、および100を超えるジャーナルを発行しています。専門家の間で人気があります。 さらに、協会は年間300を超える主要な会議を開催しています。 IEEEは、900を超える既存の標準（www.ieee.ru/ieee.htm）の開発に参加しています。 現在、この研究所は規格の作成、調整、承認、公開に取り組んでいますが、正式なステータスのため、国際規格や国内規格などの文書を採用する権限はありません。 したがって、IEEEの理解における「標準」という用語は、むしろ「仕様」として理解されるべきであり、これは、協会によって受け入れられた文書のステータスとより一致しています。 IEEEに従って、IEC、ISO、ITU（国際電気通信連合）、ETSI（欧州電気通信標準化機構）、CENELEC（欧州電気標準化委員会）、および国内の多くの国際および地域組織のプログラムに参加しています。たとえば、ANSIのような組織のプログラムのプログラム。

IEEEには、POSIXファミリの標準（www.pasc.org/）を開発する協会委員会であるPASC（Portable Application Standards Committee）が含まれています。 PASCは、以前はオペレーティングシステム技術委員会として知られていました。

仕事の2番目の参加者- ANSI（American National Standards Institute、American National Standards Institute）-米国で標準化活動を管理および調整する民間の非営利団体。 従業員は75人だけですが、ANSIメンバーには、1,000以上の企業、組織、政府機関、および機関が含まれています（www.ansi.org）。 ANSIは、ISOとIECという2つの主要な国際標準化機構で米国を代表しています。

3番目の参加者- ISO（国際標準化機構）。 これは、1946年に標準化機構委員会と国連総会の決定により作成され、1947年2月23日に正式に作業を開始しました（www.iso.org）。 ISOは、ジュネーブ（スイス）に中央事務局を置く146か国（1か国-1つのISOメンバー）の国家標準化機構のネットワークです。 ISO規格は技術委員会で開発され、その最初の製品はドラフト国際規格（DIS）であり、いくつかの承認の後、最終ドラフト国際規格（FDIS）になります。 その後、この文書の承認の問題が投票にかけられます。 成功すれば、それは国際標準になります。

そして最後に - IEC（国際電気標準会議、国際電気標準会議-IEC）、1906年に設立されたIECは、すべての電気、電子、および関連技術の国際規格を作成して公開しています（www.iec.ch/）。 2004年11月1日の時点で、64か国の国内委員会がこの委員会の積極的なメンバーでした。 IECは、英語とフランス語で公開され、国際規格のステータスを持つ推奨事項も公開しています。 それらに基づいて、地域および国の基準が作成されます。 技術委員会（TC）は、特定のTCの活動に関心のある国内委員会が参加するIEC活動のさまざまな分野における規格の作成に責任があります。

IECは、国際情報技術規格の作成における重要な組織です。 この分野では、情報技術に関する合同技術委員会、JTC 1があり、IECとISOの間の合意に従って1987年に設立されました。 JTC1には17の小委員会があり、ソフトウェアからプログラミング言語、コンピューターグラフィックスと画像編集、機器の相互接続、安全対策まですべてを監督しています。

新しいIEC規格の準備には、いくつかの段階（予備、提案段階、準備段階、技術委員会段階、要求段階、承認段階、公開）が含まれます。 IEC文書が技術仕様のみであり、国際規格ではないことを意図している場合、文書の改訂版が本部に送信されて公開されます。 国際規格（FDIS）の最終ドラフトは、完了するまでに4か月かかります。 技術委員会のすべてのメンバーによって承認された場合、FDIS承認段階なしで公開のために中央オフィスに送信されます。 その後、FDISは国内委員会に行き、2か月以内に承認する必要があります。 FDISは、国内委員会の3分の2以上が投票し、反対票の数が25％を超えない場合、承認されたと見なされます。 文書が承認されない場合は、技術委員会と小委員会に改訂のために送信されます。 この規格は、FDISの承認後2か月以内に公開する必要があります。

他のいくつかの組織がPOSIX標準の開発と採用に関与しています。

オープングループソフトウェア標準化のための国際組織であり、情報技術の分野で働く約200のメーカーとユーザーコミュニティを統合しています（www.opengroup.org/）。 Open Groupは、その2つの前身であるX / OpenとOpenSoftware Foundation（OSF）の合併により1995年に設立されました。 Open Groupは、ソフトウェア認証方法論とコンプライアンステストの開発を専門としています。 特に、Open Groupは、COEプラットフォーム、CORBA、LDAP、Linux Standard Base、Schools Interoperability Framework（SIF）、S / MIME Gateway、Single UNIX Specification、Wireless Application Protocol Specification（WAP）、そして最後にPOSIXファミリの標準（www.opengroup.org/certification/）。

オースティン共通規格改訂グループ（CSRG）-共同技術 ワーキンググループ 2002年にISO、IEC、およびOpen Groupによって設立され、作成および維持されています。 最新バージョン標準1003.1。これは、ISO / IEC 9945-1-1996、ISO / IEC 9945-2-1993、IEEE Std 1003.1-1996、IEEE Std 1003.2-1992、およびSingle UNIX Specification（www.opengroup.org）に基づいて作成されます。 / press / 14nov02.htm）。

米国国立標準技術研究所（NIST）-1901年に米国で設立された、商務省の技術局（www.nist.gov/public_affairs/general2.htm）内の連邦機関。NISTの使命は、製品の品質を向上させるための標準と技術を開発および促進することです。 NISTには、情報技術研究所（ITL）が含まれており、その結果の1つが連邦情報処理標準（FIPS、www.opengroup.org / tests / fips / general_info.html）です。 NIST / ITLは、1991年にFIPS PUB 151-11990の下でPOSIX認証の初期セットのテストを提供しました。

POSIXとは何ですか？

正式には用語 POSIXリチャード・ストールマンが略語として提案した NS ortable Oペラペラ NS国連のシステムインターフェース IX（Unix用のポータブルオペレーティングシステムインターフェイス）。 POSIXは、アプリケーションにソースの移植性を提供することを目的として、UNIXライクなオペレーティングシステム（初期のバージョンは1970年代初頭にさかのぼります）用に開発されました。

インターフェイスの最初の説明は、IEEE-IX（IEEEのバージョンのUNIX）と呼ばれた1986年に公開されました。しかし、名前はすぐに変更され、POSIXになり、次の公開（1986年に遡る）でこの新しいバージョンが使用されていたしばらくの間、POSIXは、関連ドキュメントのグループIEEE1003.1-1988およびISO / IEC 9945の一部への参照（または同義語）として、また完全で承認された国際標準ISO / IEC 9945.1：1990POSIXとして理解されていました。 POSIX仕様は、アプリケーションプログラムとOSの間の相互作用の標準メカニズムを定義し、現在、IEEE、ISO、IEC、およびANSIの支援の下で30を超える標準を含んでいます。

POSIXはその歴史を通じて長い道のりを歩んできました。仕様の指定、具体的な内容、手順、検証のロジスティクスは何度も変更されました。 それ以来、POSIX標準のいくつかのエディションがさまざまな国際機関の枠組みの中で発行されています。

POSIX標準の開発の歴史

IEEE Std 1003.1仕様の最初のバージョンは、1988年に公開されました。その後、IEEE Std1003.1の多数のエディションが国際標準として採用されました。

POSIX開発段階：

1990年

1988年にリリースされたこのエディションは改訂され、さらなる改訂と追加の基礎となりました。 これは、国際規格ISO / IEC 9945-1：1990として承認されています。

1993年

エディション1003.1b-1993が公開されています。

1996年

IEEE Std 1003.1b-1993、IEEE Std 1003.1c-1995、および1003.1i-1995に変更が加えられましたが、ほとんどのドキュメントは変更されていません。 1996年には、IEEE Std 1003.1の改訂版も、国際規格ISO / IEC 9945-1：1996として承認されました。

1998年

「リアルタイム」の最初の標準が登場しました-IEEEStd1003.13-1998。 これは、リアルタイム組み込みアプリケーション向けのPOSIX標準の拡張です。

1999年

1003.2規格（シェルとユーティリティ）との統合を含め、過去10年間で初めて規格の本文に大幅な変更を加えることが決定されました。これは、当時は別個の規格であったためです。 PASCは、IEEE標準1003.1a、1003.1d、1003.1g、1003.1j、1003.1q、および1003.2bの完了後に、ベーステキストの変更を確定することを決定しました。

2004r。

1003.1の最新のリビジョンは、4月30日に公開され、Austin Common Standards RevisionGroupの支援の下でリリースされました。 これは、2001年版の規格に合わせて修正されています。正式には、2004年版はIEEE Std 1003.1、2004 Edition、The Open Group Technical Standard Base Specification、Issue 6として知られており、IEEE Std 1003.1-2001、IEEE Std 1003.1-2001 / Cor1-2002およびIEEEStd 1003.1-2001 / Cor2-2004。

RTOSの最も重要なPOSIX標準

リアルタイムオペレーティングシステムの場合、標準の7つの仕様（1003.1a、1003.1b、1003.1c、1003.1d、1003.1j、1003.21）が最も重要ですが、商用オペレーティングシステムで広くサポートされているのは3つだけです。

• 1003.1a（OS定義）メインOSインターフェイス、ジョブ制御、信号、ファイルシステムの機能を定義し、デバイス、ユーザーグループ、パイプライン、FIFOバッファーを操作します。
• 1003.1b（リアルタイム拡張機能）リアルタイム信号、優先順位スケジューリング、タイマー、同期および非同期I / O、セマフォ、共有メモリ、メッセージなどのリアルタイム拡張について説明します。 当初（1993年以前）、この標準はPOSIX.4と呼ばれていました。
• 1003.1c（スレッド）スレッドサポート関数（スレッド制御、スレッド属性、ミューテックス、ディスパッチ）を定義します。 当初はPOSIX.4aとして指定されていました。

これらの標準に加えて、以下の標準がRT OSにとって重要であり、Std1003.1-2001プロジェクトの作業の一部として実装されました。

• IEEE1003.1d-1999。追加のリアルタイム拡張。 当初はPOSIX.4bとして指定されていました。
• IEEE1003.1j-2000。改善された（高度な）リアルタイム拡張。
• IEEE1003.1q-2000。トレース。

認証手続き

POSIXに準拠するには、オペレーティングシステムが適切なテストスイートに対して認定されている必要があります。 POSIXの導入以来、テストスイートは正式および事実上の変更を受けています。

1991年、NISTはFIPS 151-1（http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf）に基づいてPOSIXテストプログラムを開発しました。 このテストオプションは、IEEE 1003.3「POSIXへの適合性を測定するためのテスト方法の標準」ドラフト10、1989年5月3日に基づいていました。1993年、NISTはFIPS 151-1のPOSIXテストプログラムを完了し、FIPS 151-2のプログラムを開始しました。 （www.itl.nist.gov/fipspubs/fip151-2.htm）。 FIPS 151-2は、ISO / IEC 9945-1：1990標準である「情報技術-ポータブルオペレーティングシステムインターフェイス（POSIX）-パート1：システムアプリケーションプログラムインターフェイス（API）」を採用しています。 FIPS 151-2のテストスイートは、IEEE2003.1-1992「POSIXへの適合性を測定するためのテスト方法の標準」に基づいています。

NISTは、自己認証とIEEE認定試験所（Accredited POSIX Testing Laboratories-APTL）による認証の2つの認証方法を区別しています。 最初のケースでは、会社は独自にテストを実施しますが、NISTによって承認された計画に従っています。 2番目のケースでは、テストは自動テストスイートを使用して独立した研究所によって実行されます。 合計で、2つのAPTLラボが認定されています。Mindcraft（www.mindcraft.com）とPerennial（www.peren.com）です。

1997年、NIST / ITLは、今年の終わり（正式には1997年12月31日）にFIPS 151-2認証を終了する意向を発表しましたが、OpenGroupは同年10月1日から引き継ぐことを発表しました。 NIST / ITLプログラムに基づく、FIPS151-2に準拠した年次認証サービス。 1998年1月1日以降、同じ機能がIEEE Standards Association（IEEE-SA）に引き継がれ、FIPS151-2にも基づいています。

2003年、IEEE-SAとOpen Groupは、IEEE1003.1™2001以降の最新のPOSIXバージョンを認定するための新しい共同プログラムを発表しました。OpenGroupには、IEEE Std 1003.1-1996、IEEE Std1003.2-1992をカバーするいくつかのテストスイートがあります。 、IEEE Std1003.1-2003およびIEEEStd 1003.13-1998（www.opengroup.org/testing/testsuites/posix.html）。 製品が完全な認証手順に合格した場合、その製品はすべての要件を満たし、認証製品の公式登録に登録されているテスト結果に従って、POSIX認証済みと見なされます。

テストスイートには次のものが含まれます。

• VSX-PCTS1990（www.opengroup.org/testing/testsuites/vsxpcts1990.htm）-システムインターフェイスIEEE Std1003.1-1990の一連の適合性テスト。
• VSPSE54（www.opengroup.org/testing/testsuites/VSPSE54.htm）-IEEE Std 1003.13-1998プロファイルPSE54（多目的リアルタイム）の一連の適合性テスト。
• VSX-PCTS2003（www.opengroup.org/testing/testsuites/vsxpcts2003.htm）-システムインターフェイスIEEE Std 1003.1-2003の一連の適合性テスト（必須部分のみ）。
• VSC-PCTS2003（www.opengroup.org/testing/testsuites/vscpcts2003.htm）は、IEEE Std 1003.1-2003（シェルおよびユーティリティ-必要な部品のみ）の一連の適合性テストです。

さらに、Open Groupは、POSIX RealtimeStandardsおよびEmbeddedPOSIX StandardsProfileのベンチマークを開発しました。 POSIX Realtime Test Suite（www.opengroup.org/testing/testsuites/realtime.html）には、次のテストが含まれています。

• IEEE POSIX 1003.1b-1993 /1003.1i-1995リアルタイム拡張およびIEEEPOSIX 1003.1,2003 Edition;
• IEEE Std POSIX 1003.1c-1995スレッド（pthreads）拡張およびIEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX1003.1d-1999追加のRealtimeExtensionおよびIEEEPOSIX 1003.1,2003Edition。
• IEEE POSIX 1003.1j-2000 Advanced RealtimeExtensionおよびIEEEPOSIX 1003.1,2003 Edition;
• IEEE POSIX1003.1q-2000トレースおよびIEEEPOSIX 1003.1,2003EditionおよびIEEEPOSIX 1003.1,2003Edition。

Embedded POSIX Standards Profile Test Suite（www.opengroup.org/testing/testsuites/embedded.html）には、次のテストが含まれています。

• IEEE POSIX 1003.1-1990（5310テスト）;
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995リアルタイム拡張（1430テスト）;
• IEEE Std POSIX 1003.1c-1995スレッド（pthreads）拡張（1232テスト）;
• IEEE POSIX1003.13-1998プロファイル52。

用語の混乱について少し

英語の標準のPOSIXグループに関連して、1つではなく、3つもの用語がよく使用されます。 残念ながら、それらは意味が似ており、同じように翻訳されることが多く、混乱を招きます。 これらの用語は次のとおりです。

• 互換性（文字通り-「互換性」）;
• コンプライアンス（文字通り-「コンプライアンス」）;
• 適合性（文字通り「一貫性」）。

POSIXに適用される最初の用語は正式には定義されていません。 2つ目は、組織（ソフトウェア製品の製造元）が、この製品の全体または一部が、リストされているNIST-PCTS標準に準拠していることを独自に宣言していることを意味します。 第3項は、 ソフトウェア認定された研究所またはオープングループ内のいずれかで確立されたテストシステムに合格し、これに関する証拠書類（いわゆる適合性ステートメント）があります。 さらに記事の本文では、あいまいさを排除するために、用語の元の部分がどこでも引用されます。

認定OSRV

認定されたRTOSのデータを公式登録簿に公開し、適合レベルでテストを実行することを要求する厳格な規則を遵守している場合、現在、認定されたRT OSは2つしかありません（データは時系列で示されています）。

LynxOS v.3（Lynx Real-Time Systemsの製品、現在はLynuxWorks、Inc.、www.lynuxworks.comと呼ばれています）は、ハードリアルタイムで動作する組み込みシステム、OEMおよび通信機器メーカー、特にオンボードシステムのメーカー向けのソフトウェアを開発するように設計されています。軍事用途向け..。 開発は、ターゲットシステム自体（セルフホスト）とインストルメンタルコンピューター（ホスト）の両方で実行でき、完成したソフトウェアはターゲットシステム（ターゲット）で動作するように設計されています。 LynxOS v.3は、IntelおよびPowerPCプラットフォームでPOSIX準拠の認定を受けています。 これに関する情報は、IEEE Webサイト（http://standards.ieee.org/regauth/posix/posix2.html）にあります。 LynxOSは、NIST FIPS151-2適合性テストスイートのIEEEPOSIX認定POSIXテストラボであるMindcraftによってPOSIX1003.1-1996認定を受けています。 認証文書番号：参照ファイル：IP-2LYX002、参照ファイル：IP-2LYX001。

整合性v.5（Green Hills Softwareの製品、www.ghs.com）は、2004年7月にPOSIX 1003.1-2003、PowerPCアーキテクチャのシステムインターフェイス（http://get.posixcertified.ieee.org/select_product.tpl）への準拠が認定されています。 VSX-PCTS2003テストスイート。

POSIXとQNXオペレーティングシステム

QNX v.4.20（QNX Software Systems、www.qnx.comによって開発された）は、DataFocusIncorporatedによってIntelプラットフォームのPOSIX1003.1-1988準拠認定を受けています。 テストは1993年9月13日に実施され、1993年11月1日に発行されました。NISTPCTS151-1テストスイート、バージョン1.1。

QNX Neutrino（バージョン6.3）は、次のPOSIXファミリ標準（www.qnx.com/download/download/8660/portability.pdf）に準拠しています。

• POSIX.1（IEEE 1003.1）;
• POSIX.1a（IEEE 1003.1a）;
• POSIX.2（IEEE 1003.2）;
• POSIX.4（IEEE 1003.1b）;
• POSIX.4a（IEEE 1003.1c）;
• POSIX.1b（IEEE 1003.1d）、IEEE 1003.1j;
• POSIX.12（IEEE 1003.1g）。

QNXNeutrinoの作成者であるQNXSoftware Systemsも、QNXNeutrinoがこれらの標準のいくつかに準拠することを計画しています。 工事は2005年に予定されています（www.qnx.com/news/pr_959_1.html）。

文学

1. IEEE StandardsAssociation操作マニュアル。 IEEE、2004年10月。
2. ケビン・M・オベランド。 POSIX in Real-Time、組み込みシステムプログラミング、2001年。
3. IEEE / ANSI標準1003.1：情報技術-（POSIX）-パート1：システムアプリケーション：プログラムインターフェイス（API）。
4. ガルマイスター、B。O。 実世界のためのプログラミング、POSIX.4セバストポル、カリフォルニア州：O'Reilly＆Associates、1995年。
5. 米国国立標準技術研究所、PCTS：151-2、POSIXテストスイート。
6. POSIX：IEEEおよびThe OpenGroupによって認定されています。認定ポリシー。 The Open Group、2003年10月21日、リビジョン1.1。

アレクセイ・フェドルチュク
2005年

POSIXファミリオペレーティングシステムのファイルシステムの論理構造の特徴的な機能の1つは、階層的またはツリーのような編成です（ただし、私が言ったように、ツリーは少し奇妙に見えます）。 つまり、あらゆる種類のDOSやWindowsと同様に、個々のメディアとそのパーティションの指定（アルファベットなど）はありません。これらはすべて、メインディレクトリのサブディレクトリとして単一の構造に含まれています。 ルートと呼ばれます。 接続プロセス ファイルシステムファイルツリーのルートへの独立した物理メディア（およびそれらのパーティション）では、マウントと呼ばれ、それらに含まれるサブディレクトリはマウントポイントと呼ばれます。

歴史的に、Unixは、一般的にはファミリ全体で非常に類似しているが、詳細はわずかに異なる特定のディレクトリ構造を開発してきました。 特に、BSDシステムのファイル階層はほとんど同じですが、Linuxのファイル階層とは異なります。 後者では、異なる分布間で大きな違いが見られます。 ファイル階層の構造がディストリビューション固有の機能の1つである限り。

このような状況では、クロスプラットフォームアプリケーションを作成することが困難になります。 したがって、ファイル階層を標準化するためのプロジェクト、FHS（Filesystem Hierarchy Standard）が存在し、積極的に開発されています。

FHSプロジェクトは、主に多数のLinuxディストリビューションのディレクトリ構造を合理化することを目的としていました。 それは後で他の人のために適応されました Unixライクなシステム（BSDクランを含む）。 そして今、それをPOSIXシステムの標準にするための積極的な（しかしあまり成功していない）努力が、名前だけでなく実際にもあります。

FHS標準は、2つの基本原則に基づいています。1つは共有と非共有のディレクトリのファイル階層を明確に分離し、もう1つは不変と可変です。

共有ディレクトリと非共有ディレクトリの違いは、Unix固有のネットワークの性質に由来します。 つまり、ローカルマシンに関連するデータ（たとえば、そのデバイスの構成ファイル）は、ローカルまたはグローバル（ユーザーだけではない例）のネットワーク上の他のマシンからコンテンツを利用できるディレクトリとは別のディレクトリに配置する必要があります。データだけでなく、プログラム）..。

不変ディレクトリと可変ディレクトリの間の対立の本質は、例を使って簡単に説明できます。 したがって、同じ一般的なユーザープログラムは、その性質上、不変である必要があります（つまり、システム管理者のみが変更でき、作業でそれらを使用するユーザー自身は変更できません）。 同時に、これらのプログラムは、作業中にテキストや画像などのデータファイル（コメントなしで変数の性質が明確）だけでなく、ログファイルや一時ファイルなどのあらゆる種類のサービス情報を生成します） 。 これらは、実行に必要な実際の実行可能プログラムファイル、ライブラリ、構成ファイルなどとは別のディレクトリにグループ化する必要があります。

それにもかかわらず、最も一般的なものの中から多くのLinuxディストリビューションで積極的に宣伝されているにもかかわらず、FHSは真の標準のステータスを取得していません。 一部のプロビジョニングを使用しないLinuxディストリビューションは多数あります。 また、BSDシステムの従来のファイル階層と部分的にしか相関していません。

その理由は、FHSがもう1つの反対を無視するためです。これは、ユーザーにとって非常に重要です。ファイルシステムの簡単に回復できる部分と、回復が困難またはまったく回復できないコンポーネントの反対です。

最初の、奇妙なことに、基本システム自体に起因する可能性があります。結局のところ、致命的なクラッシュが発生した場合に、配布メディアから再インストールすることはそれほど難しくありません。 ファイルシステムの回復が難しい部分には、明らかにユーザーデータが含まれています。定期的にバックアップされている場合でも（そして何人のユーザーが非常に注意しているのでしょうか）、アーカイブからの展開には多くの時間がかかります（ほとんど必然的にいくつかのデータが必要になります）。損失）。

さらに、BSDシステムとソースベースのLinuxディストリビューションでは、パッケージ管理に関連するすべてのものを、回復が難しいディレクトリとして分類します-NetBSD（およびそれを借用したシステム）のFreeBSDポートツリーまたはpkgsrc、Linuxディストリビューションの対応するもの、移植されたプログラムの実際のソース、およびシステムのソースコードも。 なぜなら、これらすべてが配布キットに含まれている場合でも、ファイルシステムのこれらのコンポーネントは、原則として、ネットワークを介してプロジェクトサーバーと同期することにより、ユーザーによって最新の状態に保たれます（そうでない場合、それらの使用は無意味です）。 そして、それらの損失は、一時的な（特にモデム接続の場合）損失と経済的な（無料のインターネットアクセスの幸せな所有者である人はほとんどいない）損失の両方を伴います。

共有ディレクトリと非共有ディレクトリ、不変と不変、回復可能と回復不可能なディレクトリを互いに分離するという概念を厳密に順守することで、単一のツリーのようなファイル階層内で、個々のブランチを物理的に、つまり形式で分離できます。分離されたデバイス（ディスク、ディスクパーティション、スライス、パーティションなど）に配置された独立したファイルシステムの。 これには多くの理由があります-パフォーマンスの向上と信頼性の向上の両方、そして単に利便性の考慮-しかし、ここではそれらについては説明しません。 なぜなら この瞬間重要なのは、ファイルツリーのこれらのブランチを共通のファイルシステムに組み込む必要があるということです。

典型的なPOSIXシステムディレクトリセット

実際のところ、機能するためには、ファイルシステムが1つだけ必要です。ファイルシステムは、ファイルツリー（世界樹ユグドラシルの一種の類似物）のルートディレクトリにマウントされています。 ルートディレクトリとその不可欠なブランチは、1つのメディア（ディスク、ディスクパーティション、ソフトウェアまたはハードウェアRAIDアレイ、またはLVMを理解する上での論理ボリューム）に配置された単一のファイルシステムを構成する必要があります。 また、システムの起動に必要なすべてのコンポーネントが含まれている必要があり、理想的にはそれ以上のものは含まれていません。

次のコマンドを使用して、ルートディレクトリの構成を表示できます。

$ ls -1 /

これは、どのPOSIXシステムでも、最小限の紳士のディレクトリセットを表示します。

ビン/ブート/ etc /ルート/ sbin /

すべてのファイルが収集されるのはそれらの中にあり、それなしではシステムは存在できません。 他のディレクトリは次のようなものです。

ホーム/ mnt / opt / tmp / usr / var /

それらはa）必須ではありません（少なくとも理論的には-それらなしで行うことは実際には困難です）、b）それらのすべてがすべてのシステムとディストリビューションに存在するわけではありません、そしてc）それらのそれぞれは可能です（そしてしばしばそうです-もしあなたはあなたの心に従ってすべてをします）ファイルツリーのそれ自身のブランチのマウントポイント。

さらに、ほとんどの場合、POSIX互換OSのファイルシステムのルートにはさらに2つのサブディレクトリがあります。

Dev / proc /

これらは通常、仮想ファイルシステムのマウントポイントであり、それぞれデバイスとプロセスです（ただし、デバイスのファイルシステムを使用しない場合は、/ devディレクトリをルートファイルシステムのコンポーネントにする必要があります。最後に、Linuxシステムでは次のようになります。ルールとして、ファイルツリーのルートはメインシステムライブラリの/ libディレクトリもあり、udevでは、必然的な/ sysディレクトリもsysfs仮想ファイルシステムがマウントされる場所です。

ルートファイルシステム

ルートファイルシステムは共有できず（つまり、ネットワーク上の異なるマシンで共有することを意図していません）、不変です（つまり、システム管理者だけが変更を加えることができますが、ユーザープログラムはできず、さらにユーザーはできません）。 さらに、標準で提供されている（および上記にリストされている）サブディレクトリを超えるサブディレクトリを作成することは強くお勧めしません。

ルートファイルシステムの入力は、他のすべてのファイルシステムがマウントされていない場合（したがって、次のようなブランチ）、緊急ブート中（またはシングルユーザーモード）でもマシンが起動して最小限の機能を保持できるように選択されます。 / usrまたは/ varが使用できない場合があります。

したがって、マシンの起動は、ディレクトリファイル/ bootなどによって提供されます。 1つ目は、システムのカーネル（「特別な目的」の実行可能ファイル）と、それをロードするために必要なすべてのもの（Linux、たとえばシステムマップ（/etc/System.map））、およびFreeBSD（ロード可能なカーネルモジュール）を含みます。 。 ただし、カーネルがファイルシステムのルートに直接配置されている場合は、/ bootディレクトリがまったく存在せず、/ modulesディレクトリがカーネルモジュール用に予約されていることがあります。

/ etcディレクトリは、それをロードするための条件を決定するシステム全体の構成ファイル用です。 その内容はシステム（およびLinuxでは配布キットにも依存します）に大きく依存するため、ここでは考慮しません。このトピックに何度も戻る必要があります。

最低限必要な機能は、/ binディレクトリと/ sbinディレクトリの内容によって提供されます。これらには、最も重要なユーザープログラムとシステムプログラムの実行可能ファイルが含まれています。これらのファイルには、複雑な修復とレスキュー対策を実行できます。故障した後、車を人間の形にします。

システムプログラムとユーザープログラムのルートサブディレクトリへの分割はかなり恣意的です。 これらのコマンドはいずれも、実際にはユーザーの問題を解決することを目的としたものではありません。 / binディレクトリには、通常のユーザーが時々アクセスする（またはアクセスできる）管理コマンドが含まれているだけです。sbinディレクトリは、ユーザーが知らないはずのコマンドを対象としています。 そして、ほとんどの場合、適切な権限（たとえば、デバイスファイルへの必要なアクセス権）が不足しているため、彼はまだ使用できません。

POSIXプログラム（/ binおよびsbinディレクトリにコンパイルされたものを含む）を実行するには、原則として、システム全体のライブラリ（主にメインのglibcライブラリ）の機能にアクセスする必要があります。 したがって、ルートディレクトリの（ほぼ）不可欠なコンポーネントは、それらがアセンブルされる/ libサブディレクトリです。

Linuxでは、/ libディレクトリは別の重要な目的を果たします。そのサブディレクトリ（/ lib / modules）には、ロード可能なカーネルモジュールが含まれています（FreeBSDでは、その場所は/ boot / kernelです）。

FreeBSDはルートファイルシステム上の/ libディレクトリを検出しません-対応するコンポーネントはここ/ usr / libに配置されます（以下を参照）。 これは、歴史的に、FreeBSDが主要なシステム全体のプログラムを構築しており、必要なライブラリ関数が実行可能ファイルに埋め込まれているためです（静的リンクと呼ばれます。これについては第14章で説明します）。 FreeBSDでは、/ binおよび/ sbinディレクトリからの5番目のブランチプログラムは動的にリンクされます。つまり、/ usrディレクトリがない場合（そしてFreeではほとんどの場合ファイルシステムの別のブランチです）、それらは機能しません。 これを補うために、標準を超え、同じプログラムを含むが静的にリンクされた/ restoreディレクトリがあります（ディレクトリの名前が示すように、その内容の唯一の目的はレスキュー操作です）。

最後に、/ root。 これは、同じ名前のユーザー、つまりシステム管理者の通常のホームディレクトリです。 実際の作業は行わないため（または少なくとも行うべきではありません）、その内容はスーパーユーザー自身の構成ファイル（ユーザーのコマンドシェル、お気に入りのエディターなど）にすぎません。

/ usrブランチ

歴史的に、/ usrディレクトリはユーザープログラムとデータを対象としていました。 これらの関数は現在/ usr / localと/ homeに分割されています（ただし、後者はFreeBSDではデフォルトで/ usr / homeへのシンボリックリンクになっています）。 / usrディレクトリ（変更可能ではありませんが共有）は、アプリケーションプログラムの大部分と、それらに関連するすべて（ソースコード、構成ファイル、共有ライブラリ、ドキュメントなど）のリポジトリとして機能します。

/ usrディレクトリの構成は、BSDシステムとLinuxで大きく異なります。 最初は、オペレーティングシステムの不可欠な部分（FreeBSDではディストリビューションの概念によって統合されている部分）のみが含まれています。 ポートまたはパッケージからインストールされたアプリケーションは、サブディレクトリ/ usr / localに配置されます。これは、ファイルツリーの個別のブランチを表すことができます。

Linuxでは、/ usrディレクトリは、配布キットに含まれるすべてのプログラム（およびそのコンポーネント）のリポジトリとして機能します。 また、サブディレクトリ/ usr / localは通常、ソースから独立してコンパイルされるプログラムを対象としています。

いずれの場合も、/ usrディレクトリの通常の構成は次のとおりです（ls -1コマンドによって報告されます）。

X11R6 / bin / etc / include / lib / libexec / local / sbin / share / src /

すでに述べたように、/ usr / localサブディレクトリはファイルツリーの個別のブランチであるため、個別に考慮されます。 他のディレクトリの目的は次のとおりです。

• / usr / binおよび/ usr / sbinは、ユーザーおよびシステムプログラムの実行可能ファイル（ここでは、ルートディレクトリの場合よりも境界が任意です）を対象としています。その目的は、システム;
• / usr / etcは、個々のアプリケーション構成ファイル用です。
• / usr / includeには、リンクに必要ないわゆるヘッダーファイルが含まれています 実行可能ファイルライブラリコンポーネントを使用。
• / usr / libおよび/ usr / libexecは、ユーザーアプリケーションが依存する共有ライブラリのディレクトリです。
• / usr / share-最も多様な、いわゆるリポジトリ。 アーキテクチャ的に独立したコンポーネント：ここでは、さまざまな形式のドキュメント、構成ファイルの例、コンソール管理プログラムで使用されるデータ（フォント、キーボードレイアウト）、およびタイムゾーンの説明を確認できます。
• / usr / src-ソースコードディレクトリ; Linuxでは、システムのカーネル（カーネル）のソースコードのみが通常ここに配置されます。BSDクローンでは、複合体のソースの完全なセットであり、FreeBSDではディストリビューションと呼ばれます。 原則として、自己組織化プログラムのソースをここに配置することは望ましくありません。
• / usr / X11R6-Xウィンドウシステムコンポーネントのディレクトリ-実行可能ファイル（/ usr / X11R6 / bin）、ライブラリ（/ usr / X11R6 / lib）、ヘッダー（/ usr / X11R6 / include）、ドキュメント（/ usr / X11R6 /男）; Xアプリケーションファイルはここに配置しないでください（おそらくウィンドウマネージャーの場合を除く）。それらの場所は、システムに応じて/ usr、/ usr / local、または/ optにあります。

さらに、/ usrディレクトリにはサブディレクトリ/ usr / varおよび/ usr / tmpが含まれる場合があります—通常はルートディレクトリの対応するブランチへのシンボリックリンクです。 また、一部のLinuxディストリビューションでは、システム全体のメインドキュメントであるmanページ（/ usr / manサブディレクトリ内）が/ usrに直接配置されています。

最後に、BSDシステムおよび一部のソースベースのLinuxディストリビューション（Gentooなど）では、/ usrディレクトリにパッケージ管理システムのサブディレクトリが含まれています-FreeBSDおよびOpenBSDポート（/ usr / ports）、他のシステムの対応するもの（/ usr / Portage in Gentoo）。 FHS標準の文字と精神に従うという観点からは（彼自身はポートや同様のシステムについての言葉は言及していません）、それらを配置するためのより論理的な場所は/ varディレクトリ（以下を参照）です-そしてこれはまさにCRUXやArchlinuxなどのディストリビューションで行われていることです。

ブランチ/ usr /ローカル

すでに述べたように、Linuxの/ usr / localブランチは、ソースからのプログラムの自己コンパイルを目的としています（この配布キットには含まれていません）。 また、FreeBSDでは、ほとんどすべてのユーザーのアプリケーションのホームとして機能します。ディストリビューション以外のほとんどすべてのもので、パッケージまたはポートからインストールされます。 したがって、ディレクトリ構造は/ usrブランチの構造とほぼ同じです（理解できる例外があります）。

ビン/ etc / include / lib / man / sbin / share /

サブディレクトリの内容も同様です：プログラム実行可能ファイル（/ usr / local / binおよび/ usr / local / sbin）、それらの構成（/ usr / local /など）、それらがリンクされているライブラリ、およびそれらのヘッダーファイル（ / usr / local / libおよび/ usr / local / include）、manページ（/ usr / local / man）、および他の形式のドキュメントを含む、アーキテクチャに依存しないあらゆる種類のもの（/ usr / local / share）。

/オプトブランチ

/ optディレクトリはFHS標準によって提供されますが、実際にはすべてのLinuxディストリビューションで使用されているわけではなく、BSDシステムでは完全に存在しません。 それにもかかわらず、デフォルトのインストールを期待して書かれるプログラムはますます増えています。

歴史的に、/ optはLinuxで商用アプリケーションやあらゆる種類の非自由ソフトウェアに使用されていました。 現在、その目的は、Qtライブラリ、すべてのコンポーネントとアプリケーションを備えたKDE、OpenOffice.orgなどの大規模な自己完結型ソフトウェアシステムをホストすることです。 ディレクトリ構造は/ opt / pkg_nameである必要があります。 これは私のシステム（Archlinux）でどのように見えるかです：

$ ls -1 / opt gnome / kde / OpenOffice.org1.1.2 / qt /

各サブディレクトリには、独自の内部構造があります。

$ ls -1 / opt / * / opt / gnome：bin / lib / man / share / / opt / kde：bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2：help / LICENSELICENSE。 htmlプログラム/ README README.html [メール保護]共有 / [メール保護] THIRDPARTYLICENSEREADME.htmlユーザー// opt / qt：bin / doc / include / lib / mkspecs / phrasebooks /プラグイン/テンプレート/翻訳/

/ opt / pkg_name内のサブディレクトリの目的は、/ usrおよび/ usr / localとの類推によって簡単に推測できます。 たとえば、/ opt / kde / binはKDEシステムとそのアプリケーションの実行可能ファイル用、/ opt / kde / etcはその構成ファイル用、/ opt / kde / includeはヘッダーファイル用、/ opt / kde / libライブラリ用、および/ opt / kde / share-ドキュメントを含む共有ファイル用です。 KDEには手動のドキュメントはありませんが、利用できる場合は（Gnomeの場合のように-インストールしませんでした。これはGimpや同様のGtkアプリケーションがプルしたものです）/ opt / pkg_name / manサブディレクトリが表示されます。 。

/ optディレクトリ構造は、歴史的に確立された（そして、同じタイプのコンポーネントをディレクトリに結合するという内部的に根拠のあるPOSIXの伝統（実行可能ファイル、ライブラリなど）から逸脱していることがわかります。$ PATH、コマンドへの迅速なアクセスを提供します（第12章で説明）、または特別なディレクトリ/ opt / binを作成し、その中に実行可能プログラムバイナリへのシンボリックリンクを配置します。したがって、一部のLinuxディストリビューション（CRUXなど）では、/ optは原則として使用されません。確かに、すべてのBSDシステムで。この方法の方が優れている可能性は十分にあります...

/ Varブランチ

名前が示すように、/ varディレクトリは、さまざまなプログラム（ソフトウェア（ブラウザなど）のキャッシュ、ログファイル、印刷スプーリング、メールシステム）の通常の動作中に生成された可変ファイルを格納することを目的としています。 メールボックス、実行中のプロセスの説明など。 特に、いわゆるダンプが配置されるのは/ varディレクトリにあります。これは、異常なシャットダウン中に生成されたRAMの状態のスナップショットであり、その理由を特定します。 これらすべてのコンポーネントの特徴は、セッション中に変更可能な特性であり、それにもかかわらず、システムを再起動したときにそれらを保持する必要があるという事実です。

/ varの内部構造はシステムごとに大きく異なるため、その構造の詳細については詳しく説明しません。 このディレクトリは、たとえば、サブディレクトリ/ var / abs（abs-Archlinux）があるArchlinuxディストリビューションで行われているように、あらゆる種類のポートのようなパッケージ管理システムのコンポーネントを配置するための論理的な場所であることに注意してください。構築システム）。

ディレクトリ/ mnt

/ mntディレクトリは、一時的に使用されるファイルシステムをマウントするためのもので、通常は次の場所にあります。 リムーバブルメディア..。 確立されたシステムでは、通常は空であり、その構造はまったく規制されていません。 ユーザーは、特定の種類のメディアのサブディレクトリを自由に作成できます。 たとえば、私のシステムでは、これらは/ mnt / cd、/ mnt / dvd、/ mnt / usb、および/ mnt / hdです-CD、DVD、フラッシュドライブ、およびリムーバブルハードドライブの場合。

FreeBSDでは、CDとフロッピーディスクをマウントするためのデフォルトのディレクトリは、ルートディレクトリに直接ある/ cdromと/ floppyです。 これは標準と完全には一致していませんが、それ自体が論理的です。任意のマシンに存在するデバイス（CD ROMなど）または最近まで存在するデバイス（フロッピードライブ）のマウントポイントがルートになります。

/ホームブランチ

/ホームディレクトリは、ユーザーのホームディレクトリをホストするためのものです。 その内容はいかなる方法でも規制されていませんが、通常は/ home /（username1、...、username＃）のように見えます。 ただし、多くのユーザーがいる大規模なシステムでは、ホームディレクトリをグループ化できます。

/ホームディレクトリには、実際のユーザーだけでなく、一部の仮想ユーザーのホームディレクトリを含めることができます。 したがって、マシンがWebサーバーまたはFTPサーバーとして使用されている場合は、それぞれ/ home / wwwまたは/ home / ftpなどのサブディレクトリが表示されます。

/ tmpブランチ

一時ファイルを保存するためのディレクトリについてのみ説明します-/ tmp。 / varコンポーネントと同様に、それらは通常の生活の中でさまざまなプログラムによって生成されます。 ただし、/ varとは異なり、/ tmpコンポーネントは現在のセッションの外部で存続することは期待されていません。 さらに、すべてのシステム管理ガイドは、定期的に（たとえば、マシンを再起動するとき）、または定期的にこのディレクトリをクリアすることを推奨しています。 したがって、/ tmpとして、ファイルシステムをRAMにマウントすることをお勧めします-tmpfs（Linuxの場合）またはmfs（FreeBSDの場合）。 これにより、再起動時にその内容が確実にクリアされるという事実に加えて、パフォーマンスにも貢献します。たとえば、一時的な製品がディスクに書き込まれず、/ tmpなどの仮想ディレクトリに配置されるプログラムのコンパイルなどです。 / obj。

多くのシステムでは、/ usr / tmpや/ var / tmpのようなディレクトリが表示されます。 これらは通常、/ tmpへのシンボリックリンクです。

ファイルシステムのパーティショニング戦略

ファイル階層についての会話の結論として、段落にリストされているディレクトリのみが強調されるべきです。 ルートファイルシステム..。 他のすべてのディレクトリ-/ usr、/ opt、/ var、/ tmp、そしてもちろん/ homeは、個別の物理メディアまたはそのパーティション上の独立したファイルシステムのマウントポイントを表すことができます。

また、 地元のネットワークこれらのディレクトリは、別のマシンに配置されている場合もあります。 たとえば、アプリケーションサーバーとして機能する1台のコンピューターには、ネットワーク上の/ usrディレクトリと/ optディレクトリが含まれ、別のコンピューターには、すべてのユーザーのホームディレクトリが含まれるファイルサーバーなどがあります。

共通のファイルツリーから分離することが推奨されるファイルシステムと、それを行う理由を決定するだけです。 これらの質問への答えは、使用するOSに大きく依存し、Linuxの場合はそのディストリビューションにも依存します。 それにもかかわらず、ファイルシステムの分離の一般原則を概説することができます。 一方では、不変および可変のディレクトリ、他方では、簡単に回復可能で、回復が困難で、実質的に回復不可能なデータの反対について覚えておく必要があるのはなぜですか。 ユーザーのデスクトップに関連してこの試みをしてみましょう。サーバーの場合、計算は大幅に異なります。

明らかに、ディレクトリ/ bin、/ boot、/ etc、/ root、/ sbin内のルートファイルシステムは、配布メディアから簡単に回復でき、実質的に変更されていないデータを含み、分離されたディスクパーティションに配置する必要があります。 Linuxでは、/ libディレクトリも追加する必要があります。 一方、GRUBをブートローダーとして使用する場合（オペレーティングシステムに関係なく）、/ bootディレクトリを別のパーティションに移動することをお勧めします。

Linuxに関する古い情報源では、/ bootディレクトリにパーティションを割り当てる別の理由について、ディスクの最初に読むことができます。1023より大きいシリンダー番号からLiloを使用してカーネルをロードできないためです。ブートローダーの最新バージョンでは、そのような制限はありません。 ただし、/ bootのパーティションを作成する場合は、それをディスクの最初に作成し、そのすぐ後ろにスワップパーティションを配置するのが理にかなっています。これにより、スワッピングを実行するときの速度が5コペイカ増加します。

そして、歴史の分野からもう1つ、ルートパーティションとブートパーティションが必ずプライマリであるという要件もかなり前に削除されました。 また、これらのファイルシステムは、拡張パーティション内の論理パーティションにうまく適合する可能性があります。

ファイルシステムの可変ブランチ（/ varおよび/ tmp）をルートパーティションの外に移動する必要があることも同様に明らかです。 さらに、後者は、以前に何度も言われたように、RAM（tmpfsまたはmfs）内のファイルシステムに配置することをお勧めします。 / varディレクトリにポートのようなパッケージ管理システムのサブディレクトリが含まれている場合（Archlinuxの/ var / abs、/ var / cache / pacman / src、/ var / cache / pacman / pkgなど）、独自のファイルを作成する必要がありますシステム。

ここで、ディレクトリ/ usrには、基本システムのコンポーネント（BSDの場合）またはユーザーアプリケーションの大部分（ほとんどのLinuxディストリビューションの場合）が含まれています。 簡単に回復できるデータが含まれており、正当な理由から、実質的に変更できないはずです。したがって、もちろん、独立したセクションで強調表示する価値があります。 さらに、その構成から、一方ではサブディレクトリ/ usr / X11R6および/ usr / localを、他方ではポートのようなパッケージ管理システムのサブディレクトリを分離することをお勧めします：/ usr / ports、/ usr / pkgsrcおよび/ usr / pkg（BSDシステム）、/ usr / portages（Gentoo Linux）など。 さらに、ポートを構築するときにネットワークからダウンロードしたソースを配置するためのサブディレクトリは、後者から分離する必要があります-/ usr / ports / distfiles、/ usr / pkgsrc / disfiles、/ usr / portages / distfilesなど。

さらに、BSDシステムでは、/ usr / srcおよび/ usr / objサブディレクトリを/ usrディレクトリから分離することは理にかなっています。これらのサブディレクトリには、基本コンポーネント（カーネルを含む）のソースとそれらのコンパイル中間製品が含まれています。 makebuildworldおよびmakebuildkernelプロシージャによって生成されます。..。

最後に、揮発性で多くの場合回復不能なデータを含む/ homeディレクトリは、ファイル階層のルートから必ず削除する必要があります。 そして、私は常にそれを別のスライス（BSDの場合）またはプライマリパーティション（Linuxの場合）のいずれかに配置しようとします。

提案されたファイルシステムのパーティション分割スキームは、過度に複雑に見えるかもしれません。 ただし、簡単に回復でき、回復が困難で回復不可能なデータの分離が保証されるため、緊急時にシステムを再インストールしたり、システム間で移行したりすることが容易になります。

その追加の利点は、ファイルツリーの個々のブランチに対して、そこにあるデータの性質に応じて、Linuxでは物理的に最適なファイルシステムを選択できることです。 たとえば、/ bootの下のパーティションの場合、Ext2fs以外のものを使用することは意味がありません。 安全でありながら最も互換性のあるExt3fsを使用してルートパーティションをフォーマットすることをお勧めします。 Archlinuxの/ var / abs、Gentooの/ usr / portagesなど、多数の小さなファイルがあるディレクトリの場合は、ReiserFSを使用することをお勧めします。結局のところ、小さなファイルの巧みな処理がそのプロファイルです。 また、巨大なマルチメディアファイルが表示される可能性のある（通常はそれ自体が非常に大きい）/ホームディレクトリでは、XFSが法廷に持ち込まれる可能性があります（ただし、測定値が示すように、ReiserFSはここではかなり適切に見えます）。 このような対策により、データストレージの信頼性とファイル操作の速度の両方を向上させることができます。

BSDオペレーティングシステムのユーザーは、代替手段なしでFFSタイプのファイルシステムに関連付けられています。 ただし、操作の余地もあります。 まず、ブロックのサイズと個々のファイルシステムのフラグメントを変更することにより、ディスク操作のパフォーマンスまたはディスクスペースの節約に貢献します。 次に、ファイルツリーの一部のブランチ（推奨事項に反して、/ tmpや/ usr / objなど）を純粋な非同期モードで恐れることなくマウントし、パフォーマンスを1〜2パーセント向上させることができます。

一般的な基準について

実践的なプログラマーの間では、プログラミングの標準はまったく必要ないという意見があります。理由は次のとおりです。

(1) それらの作者はコンピュータプログラムを書かないので、最初は無意味です。

(2) 彼らはプログラマーのイニシアチブを束縛します。

(3) プログラマーは常に標準なしで同意します。

おそらく、次の2つの状況がなければ、この意見に注意を払うべきではありませんでした。

(1) それは、実践者、つまり「ソフトウェアを発行する」人々によって表現されます。

(2) 上記の理由は、この記事の著者がCプログラミング言語の標準に関するインターネット上の出版物の1つで発見したものであり、そのような意見は「国際的な規模で」だけでなく、広く普及していることが明らかになりました。傲慢なロシアの「スーパープログラマー」の間で。

「標準」という言葉は通常、何かの材料（標準寸法、標準電圧など）に関連付けられていますが、コンピュータープログラムは無形のオブジェクト（「新しい無形」）であり、無形の領域の標準は本当に無意味ですか？

ただし、反論する例があります。 ロシア語の一連のスペル規則は基本的に標準ですが、標準化団体によって承認されていません。 さらに、スペルの規則（または、必要に応じて要件）に加えて、構文規則、そして最も重要な意味論があります。 後者は「幼稚な」質問をよく示しています：なぜ猫は猫と呼ばれるのですか？ この質問には正確な答えがあります。私たちの祖先がそう同意したからです。 イギリス人の祖先は同じ獣猫、ドイツ人の祖先-子猫などと呼ぶことに同意しました。 そして、一般的に、意味、意味論、または任意の単語または単語の組み合わせの解釈の規則は、合意の問題です。

POSIX標準の目的と「スーパータスク」

名前が示すように、POSIX（Portable Operating System Interface）は、オペレーティングシステムとアプリケーションプログラム間のインターフェイス（インターフェイス）の標準です。 プログラマーが「ベア」マシン用のプログラムを作成した（入出力プログラム、三角関数などの独自のパッケージを実装する）時代は終わりました。 POSIXテキストは、標準がオペレーティングシステムの実装の詳細に要件を課していないことを繰り返し強調しています。 これは、アプリケーションプログラマーとオペレーティングシステム開発者の間の一連の合意と見なすことができます。 したがって（ここでも、かなり広まっている意見に反して）、POSIXは、オペレーティングシステムの開発者だけでなく、とりわけ、はるかに大きなカテゴリのプログラマーにも関心があります。

この種の標準の必要性は、UNIXオペレーティングシステムが普及した1980年代には早くも認識されていました。 このシステムは統一されたシステムとして考えられていましたが、特定の実装の違いにより、あるシステム用に作成されたアプリケーションプログラムを別のシステムで実行できるとは限らないことが判明しました。 POSIXが対処しようとしているのは、ソフトウェア移植性の問題として知られるこの問題です。 この規格の初版は1988年にリリースされ（翻訳があります。を参照）、プログラムの移植性に関連するさまざまな問題はすべて、（1）アプリケーションプログラムインターフェイス、（2）コマンドインタープリターおよびユーティリティの2つの部分に分けられました。 （ユーザーインターフェイス）; これらの部分は、それぞれPOSIX.1およびPOSIX.2と呼ばれます1。

この記事では、1996年7月12日に承認された第2版（そして最後の版）であるアプリケーションプログラムインターフェイスの標準であるPOSIX.1についてのみ説明することを明確にしましょう。

規格の有益な部分は、POSIXがいくつかの「理想的な」オペレーティングシステムのインターフェースの説明ではなく、UNIXオペレーティングシステムの開発で得られた経験の一般化と体系化の結果であることも強調しています。 また、POSIXはガイドまたは 学習ガイドオペレーティングシステム上で。ただし、有益な部分には、プログラマー向けの推奨事項とプログラムフラグメントが含まれています。

この規格は、そこに記述されているインターフェース機能だけに焦点を当てて、本格的なオペレーティングシステムを作成することは不可能であると直接述べています。 （特に、POSIX.1は、ネットワーキングおよび関連するインターフェイス機能やグラフィカルインターフェイスなどの問題には対応していません。）ただし、ソフトウェアの不動化の経済的コストとその結果としてのインターフェイス統合の必要性は非常に大きいため、ほとんどのベンダーは少なくともいくつかを持っていることを好みます。ないよりも標準。 このため、多くのソフトウェア開発者はPOSIXに焦点を合わせる傾向があります。 これにより、プログラムの不動性を完全に排除しなくても、少なくともプログラムの不動部分を大幅に減らすことができます。

セマンティクスについて

前に説明したように、POSIXは、オペレーティングシステム開発者とアプリケーションプログラマーの間の一連の合意と見なすことができます。 「合意」とは、まず第一に、単語と表現の同じ解釈（意味論）を意味します。 以下は、「合意」に達することの難しさを説明するための例です。

翻訳で意味を伝える方法

まず、POSIX標準は英語で書かれているため、その性質上、あいまいさが生じ（たとえば、同じ単語が名詞、形容詞、動詞になる可能性があります）、「セマンティックトラップ」が待機していることを覚えておく必要があります。ほぼすべてのページ。 これの良い例はフィクションからの例です。 この機能を見事に使用したオスカーワイルドの最も有名な作品の1つ 英語の、-真剣であることの重要性-ロシア語で「真剣であることの重要性」として知られています。 しかし 英語名 2番目の意味があります：Earnest（serious）は、キャラクターの1人の名前であり、名前は別の方法で翻訳される可能性があります：「Ernstであることがどれほど重要か」。 ロシア語のSerebryanyという名前があり、Seriousという名前があった場合、翻訳は完全に正確であり、両方の意味が転送されます。

状況は、標準自体の名前であるポータブルオペレーティングシステムインターフェイスと似ています。 形容詞Portable（mobile）は、オペレーティングシステムとアプリケーションプログラムの両方を指しますが、ロシア語で簡単に表現することはできません。「モバイルオペレーティングシステムのインターフェイス」または「提供するオペレーティングシステムのインターフェイス」と翻訳できます。アプリケーションプログラムのモビリティ」。 2番目のオプションは、標準の開発者の意図をよりよく反映していますが、同時に最初の意味が失われています（翻訳中、より馴染みのある最初のオプションが保持されました）。

「標準」という言葉の意味論

規格の本文の前には、IEEEStandards2という単語の意味を説明する前文が付いています。 これらの説明から次のように、ロシア語の用語GOSTとは少なくとも3つの意味上の違いがあります。

(1) GOSTには法律の効力があり、その違反は起訴されると直感的に考えられます。 POSIXは一連の要件であり、その遵守は完全に任意です。

(2) GOSTはキャンセルされるまで有効です（「GOSTはキャンセルされていません」という表現を聞いたことがある人も多いでしょう）。 POSIXの前文では、標準が5年間改訂されていない場合、これは、標準で検討されている問題の関連性が失われている可能性があり、自動的にキャンセルされたと見なすことができることを意味します。

(3) GOSTは匿名です。 POSIXの導入部分は、この標準の開発に参加した人のリストを提供し、解釈の要求を送信できるアドレスも提供します。 また、各要求への応答は承認手順の対象であると述べています（つまり、標準の作成者は、応答を行う前に合意します）。

したがって、Standardのようなよく知られた単語でさえ、「standard」という単語で翻訳するにはコメントが必要です。

「すべき」、「指定されていない」、「定義されていない」、「実装で定義されている」という単語のセマンティクス

標準のセクション2は、用語と一般要件と呼ばれます。 特別な用語（「プロセス」や「セマフォ」など）の定義だけでなく、「すべき」や「かもしれない」などの一見自明の言葉も含まれています。 POSIX.1はインターフェース標準であるため、その要件はオペレーティングシステムとアプリケーションプログラムの両方に適用されます。 明示的な要件は、「shall」という単語で表されます。たとえば、「成功した場合、link（）はゼロを返します。」 この例では、オペレーティングシステムの要件について説明しています。成功するとゼロを返すように、link（）関数を実装する必要があります。

「指定されていない」および「定義されていない」という用語は、規格が選択の自由を認めているという同じ考えを表していますが、これらの用語の意味は異なります。 「指定されていない」という用語は、正しい（アクション、プログラムの構築など）について話していることを意味し、「定義されていない」という用語は、正しくない（誤っている）ことについて話していることを意味します。 規格の有益な部分は、次の説明を提供します。

「未指定」という用語は、さまざまなオプション（結果、関数呼び出しの結果など）が既知であると想定され、標準ではそれらのいずれかが許可されていることを意味します。 オペレーティングシステムの特定の実装では、任意のものを選択でき、そのようなシステムは標準に準拠していると見なされます。 アプリケーションプログラム（厳密に標準に準拠）は、どのバリアントでも正しく機能するように作成する必要があります。 そのため、この用語は、アプリケーションプログラムの要件を暗黙的に表します。

例を挙げましょう。「readdir（）関数は、ディレクトリの次の要素に関連する構造体へのポインタを返す必要があります。 「point」および「point-to-point」という名前のカタログアイテムが返されるかどうかは、標準では指定されていません。 この例では、4つの可能な結果があり、アプリケーションの要件は、それらのいずれかのために設計する必要があることです。

別の例：「指定された番号のシグナルを待機するように指示するsigwait（）関数が複数の制御スレッドで呼び出された場合、シグナルが1つ以下に到着すると、sigwait（）が戻る必要があります。 これがどのような制御フローで発生するかは、規格では指定されていません。」 この例では、さらに多くの可能性のある結果が存在する可能性がありますが、それらはすべて既知であり、アプリケーションの要件は、すべての結果に対して正しく機能する必要があることです。

「定義されていない」という用語は、多くの結果が不明であり、悲惨な結果（たとえば、システムクラッシュ、データ損失など）が発生する可能性があることを意味します。 基本的に、この用語は、アプリケーションが対応するデータまたは構成を使用しないという要件を暗黙的に表します。 例：「readdir（）のdirp引数が現在開いているディレクトリを参照していない場合、結果は未定義です。」

この例では、アプリケーションがreaddir（）関数の引数を開いているディレクトリ参照のみに置き換える必要があります。 この要件に違反すると、悲惨な結果につながる可能性があり、これに対する責任はアプリケーションプログラマーにあります。

別の例を次に示します。「成功した場合、read（）関数は、実際に読み取られたバイト数を表す整数を返す必要があります。 それ以外の場合、関数はエラーコードをerrnoに割り当てて-1を返す必要があり、bufが指すバッファーの内容は未定義です。 "

この標準では、read（）関数でエラーが発生した場合に、アプリケーションプログラムのバッファからのデータを使用することを禁止しており、この要件に違反した場合の結果はアプリケーションプログラマに割り当てられます。

「実装定義」という用語の意味は、直感的なものとは異なります。 明らかに、特定のオペレーティングシステムでは、「未指定」または「未定義」の結果はあり得ません。特定の結果が必ず得られます。 「実装定義」という用語は、オペレーティングシステムのドキュメントに対する標準の要件を表します。結果を指定するだけでなく（オペレーティングシステムの開発者はこれを行う必要があります）、システムのドキュメントに明示的に反映する必要があります。

デフォルトのセマンティクス

単一の規制文書で実際に発生する可能性のあるさまざまなケース全体を網羅できるわけではないため、必然的に何かについて沈黙しています3。 たとえば、関数の説明では、引数が特定の範囲から値をとることができると書かれている場合がありますが、引数がこの範囲に収まらない場合の結果については何も述べられていません。 明らかに、誤解を避けるために、統一されたデフォルトのセマンティクスを持つ必要があります。 標準の有益な部分には、「一般的に受け入れられているデフォルトのセマンティクスは禁止されています」という興味深いフレーズがあります。 この声明は、よく知られている10年前のスローガン「明示的に禁止されていないものはすべて許可されている」と矛盾しています。 どうやら、それは市民の心に深く根付いているので、プログラマーでさえ、多くの人が、引用された規格の声明に同意しません。 一方、構成の使用が明らかに許可されておらず、説明に従わない場合、実践的なプログラマーは、それを使用することは危険であることに気づき、それが機能しない場合、主張することはありません。

制御のプロセスとフロー

これらの用語は両方とも、並列実行の概念を表しています。 UNIXオペレーティングシステムは元々マルチユーザーとして考えられていたため、異なるユーザーによって起動されたプログラムは、誤って「外部」データを歪めないように、互いに確実に分離する必要があります。 この分離は、ユーザープログラムが独自の仮想アドレス空間で開発されるプロセス内で実行されるという事実によって提供されます。 プログラムにグローバルデータが含まれている場合でも、異なるプロセスで起動されると、それらは自動的に異なるアドレス空間に「分割」されます。

ただし、リアルタイムタスクをプログラミングする場合、プロセスメカニズムは完全に満足できるものではありません。 リアルタイムアプリケーション（同じユーザーに代わって実行される）は、スレッドと呼ばれる同時に実行される部分として自然に表現されることがよくあります。 プロセスとの最も重要な違いは、すべての制御フローが単一のアドレス空間で開発されることです。 これにより、グローバルデータにすばやくアクセスできますが、同時に、不注意による歪みのリスクがあります。これを防ぐには、プログラミングの規律を守る必要があります。 対応する推奨事項は、規格の有益な部分に含まれています。

マルチスレッドのアイデアは、多くのリアルタイムオペレーティングシステムに実装されており、各制御スレッドが異なる属性とインターフェイス機能のセットを持っているという意味で、さまざまな方法で実装されていることを強調しておく必要があります。 スレッドの代わりにタスクという用語が使用されることもあります。 混乱を避けるために、この標準では、POSIXスレッドのみを扱い、対応するインターフェイス関数の名前の前にpthread_（たとえば、pthread_create（）、pthread_join（）など）を付けることを強調しています。

標準への準拠。 「一致」という言葉の意味論

直感的には、2つのアイテムが同じ基準に従って作成された場合、それらは互いに「結合」することが保証され、ペアで連携すると考えられています。 これはまさにインターフェース（インターフェース）規格を導入する目的です。 POSIXはインターフェースの標準であるため、オペレーティングシステムとアプリケーションプログラムの両方の標準への準拠について話すことができます。

POSIX.1標準には、数百（数千ではないにしても）の要件が含まれています。 それらの少なくとも1つが満たされない場合、システム（またはアプリケーションプログラム）が基準を満たしていないことは自明であると見なされます。 同時に、これまでに非常に多くのUNIXクラスのオペレーティングシステムとアプリケーションプログラムが作成されているため、示された意味で完全なコンプライアンスを要求することはほとんど合理的ではありません。 この種の国際標準を開発することの難しさは、異なる国語の存在によって悪化します。 国語のテキストを処理することを目的としたアプリケーションプログラムを忘れたとしても、実際には、どのアプリケーションプログラムも、ある種の診断メッセージを発行したり、オペレータが入力したテキストを認識したりする必要があります。

• POSIX.1標準への厳密な準拠。
• 国際バージョンPOSIX.1への準拠。
• POSIX.1の国内バージョンへの準拠。
• POSIX.1の拡張機能への準拠。

第二に、インターフェース機能の多くはオプションです。 この標準では、オプションのインターフェイス関数が標準で規定されているとおりに動作するか、常に特別なエラーコードENOSYS（関数が実装されていないことを意味します）を返す必要があります。 オプションはいくつかのグループに分けられ、それぞれが対応するヘッダーファイルで（#defineステートメントによって）宣言されている構成定数に対応します。 これにより、コンパイルフェーズで関数が実装されているかどうかを確認できます。

説明されているモビリティを実現する方法は、POSIXの作成者によって発明されたものではありませんが、実際には長い間使用されてきました。 多くのオペレーティングシステムでは、構成定数を使用してシステム自体またはそのバージョンを識別します。 そしてここでは、標準は根本的に新しいものを提供していませんが、既存の慣行を体系化するだけです。

標準化の対象と標準の構造

要するに、POSIX.1標準化オブジェクトは名前とセマンティクスです。 具体的には、次のことを話します。

• インターフェイス関数の名前。 357個の関数が標準化され、107個の関数が標準Cライブラリ（数学、文字列処理、入出力など）から取得されます。 これらの関数はPOSIX.1標準の一部と見なされますが、 完全な説明 Cプログラミング言語の標準に含まれています。
• システムデータ型の名前。 これらの名前の末尾には_tが付いています。
• ヘッダーファイルの名前、およびこれらのファイルの最小構成。
• システム全体のグローバル変数名（たとえば、errno）。
• 関数の実行中に設定できるエラーコードの記号名。 これらの名前は文字Eで始まります（EPERM、ENOTEMPTYなど）。
• 構成定数名。 これらの名前の前には_POSIX_が付いています。
• 信号番号の記号名。 これらの名前の前にはSIGが付いています。 20個の「従来の」信号（SIGABRT、SIGALRMなど）に加えて、リアルタイム信号が標準化されています。その数は、少なくともRTSIG_MAX番号を含む、SIGRTMINからSIGRTMAXまでの特定の連続範囲を占める必要があります。
• 一部の関数の個々の引数の値に対応する記号名（たとえば、fcntl（）関数のcmd引数は、値F_DUPFD、F_GETFD、F_GETLKなどを取ることができます）。
• マクロ、定数、ビットフラグ、環境変数の名前。

一般に、この規格は、ほぼ同じ体積の2つの大きな部品で構成されています。 前半（規範的な部分）には、標準の要件と推奨事項（18セクション）が含まれ、後半（有益な部分）には、規範的な部分、ヘッダーの構成への参照、コメント、および説明のリストを提供する付録が含まれていますファイル、標準（デンマーク向け）のプロファイル（「プロジェクション」）の例、最も重要な機能のパフォーマンスを測定するための特性と方法論、およびファイルをリアルタイムで操作するための追加のインターフェイス機能の説明。 規格の将来の版では、これらの機能が規範的な部分に含まれることが期待されています。

サイドバーの「規格の条項の概要」は、どのタイプのオペレーティングシステムサービスが規格の対象であるかを示しています。

結論

POSIX標準の主な内容は、インターフェース関数のセマンティクスです。 セマンティクスの標準化はそれ自体が簡単なビジネスではなく（2人でも合意に達するのがいかに難しいかは誰もが知っています）、現在多くの人がプログラミングに携わっているという事実によって困難が悪化しています。 たとえば、並行性パラダイムは、「プロセス」、「タスク」、「制御フロー」などの用語で表されますが、実際のプログラミングの観点からは、IBM OS / 360オペレーティングシステムおよび実際の「タスク」時間オペレーティングシステムVxWorksは同じではありません。 別の例はセマフォです。 セマフォは、バイナリ、整数（「カウンター付き」）、および相互排除（ちなみに、プログラマーは、誤解を避けようと自発的に「ミューテックス」と呼びます）です。 また、たとえばVxWorksオペレーティングシステムの整数セマフォは、POSIXセマフォとまったく同じではありません。

POSIX標準の作成者は、人々に習慣を放棄させることがいかに難しいか（「確立された慣行」と呼ばれる）を十分に認識しており、従来のほとんどのサービスをカバーする一貫性のある最小限のインターフェイス機能システムをコンパイルしたと宣言しています。オペレーティングシステムによって提供され、これらの関数の正確なセマンティクスを詳細に説明し、開発でそれらを使用するようにすべての人を招待します4。

規格を読んでいると、一部の文言には単一の目的があるという印象を受けることがあります。それは、規格を満たすカテゴリからアプリケーションプログラムやオペレーティングシステムを削除しないことです。 このような目標は、「はじめに」で実際に設定され、明示的に策定されました。標準では、一般的な慣行を可能な限り考慮に入れる必要があります。 ただし、主な目標は、アプリケーションプログラムのモビリティを確保することです。

著者について

セルゲイ・ロマニュク - システム研究所の主任研究員、POSIX標準翻訳者グループの責任者。 彼は次のアドレスに電子メールで連絡できます。 [メール保護]

1 標準に関する作業は何年も続いていることを付け加えておく必要があります。 新しい問題が特定され、それらは既存のパーツの1つに含まれるか、別のパーツとして形式化され、後でキャンセルできます。 これは、たとえば、最初はPOSIX.4として宣言され、後にPOSIX.1に含まれるリアルタイムのフロントエンド機能で発生しました。

2 IEEEは、POSIX標準を開発した組織です。

3 ここで、「デフォルト」は、デフォルトではなくサイレントを意味します。 実際に宣言されているいくつかの暗黙の値について話しているのではなく、参照がまったくないことについて話しているのです。

4 この規格のロシア語訳は2000年初頭に公開される予定です。

文学

国際規格ISO / IEC 9945-1（ANSI / IEEE Std 1003.1）第2版。 1996-07-12。 情報技術-ポータブルオペレーティングシステムインターフェイス（POSIX）-パート1：システムアプリケーションプログラムインターフェイス（API）。

M.I. Belyakov、Yu.I。Rabover、A.L。Fridman モバイルオペレーティングシステム。 ディレクトリ。 モスクワ、「ラジオとコミュニケーション」、1991年。

ISO / IEC 9899：1990、プログラミング言語-C。

セクション1	- 序章
第2節	-用語と定義
セクション3	-プロセス（画像の作成、置換、完了）およびシグナル（マスクの管理、シグナルへの応答）を管理するための機能
セクション4	-識別（プロセス、ユーザー、システム、端末）、プロセスの実行に費やされた時間のポーリング、環境変数のポーリング。
セクション5	-ファイルとディレクトリの管理
セクション6	-入力および出力機能
セクション7	-端末制御機能
セクション8	-C言語標準から借用した関数
セクション9	-ユーザーおよびユーザーグループのデータベースへのアクセス
セクション10	-アーカイブと交換のためのデータ形式（tarとcpio）
セクション11	-同期機能：セマフォ、ミューテックス、条件変数
セクション12	-メモリ管理機能：プロセスのアドレス空間の固定と固定解除、ファイルのメモリへのマッピング、メモリ保護、共有メモリ
セクション13	-スケジューリングプロセスと制御フローに関連する機能
セクション14	-時計とタイマーの管理
セクション15	-メッセージキュー管理
セクション16	-制御フローに関連する基本機能
セクション17	-スレッド固有のデータ
セクション18	-制御フローの破壊手段

件名：オペレーティングシステム。
質問：8番

—————————————————————

OS構築の原則：

1.) モジュール性の原則-モジュールは、一般に、受け入れられている相互変調インターフェースに従って作成された、システムの機能的に完全な要素を意味すると理解されています。 その定義により、モジュールは、指定されたインターフェースが使用可能な場合、モジュールを別のモジュールと簡単に置き換えることができると想定しています。 多くの場合、システムのモジュールへの分割は、使用されるOS設計方法（ボトムアップまたはその逆）によって決定されます。

特権モジュール、再入可能モジュール、および再入可能モジュールは、OSを構築するときに特に重要です（再入可能は文字通り再入可能です。プログラムの状態を示す特別な用語です。プログラムのプロパティは、次の場合に正しく実行されます。割り込みからの再帰的（戻り）呼び出しが発生します）。

この原則を使用することによる最大の効果は、この原則をOS、アプリケーションプログラム、およびハードウェアに同時に拡張した場合に達成できます。

2.) 機能的選択性の原理-重要なモジュールの特定の部分がOSに割り当てられます。これは、計算プロセスをより効率的に編成するために、常にRAMに配置する必要があります。 この部分は、システムの基盤であるため、OSではカーネルと呼ばれます。 コアの構成を形成するときは、2つの相反する要件を考慮に入れる必要があります。 最も頻繁に使用されるシステムモジュールをカーネルに含める必要がある一方で、モジュールの数は、カーネルが占有するメモリの量が多すぎないようにする必要があります。 カーネルを構成し、RAMに永続的に配置されるソフトウェアモジュールに加えて、呼び出される他の多くのシステムソフトウェアモジュールが存在する可能性があります。 トランジット. トランジット ソフトウェアモジュール必要な場合にのみRAMにロードされ、不在の場合 フリースペース他のトランジットモジュールと交換できます。

3.) OSの生成可能性の原則：原則の本質は、OSの中央システム制御プログラム（カーネルとRAMに永続的に存在する主要コンポーネント）の初期提示のためのそのような方法を組織化（選択）することにあり、これによりこのシステム監視部分をカスタマイズすることが可能になりました特定のコンピューティングコンプレックスの特定の構成と解決するタスクの範囲に基づいています。 この手順は、OSの十分に長い動作期間の前に実行されることはめったにありません。 生成プロセスは、特別なジェネレータプログラムとこのプログラムの適切な入力言語を使用して実行されます。これにより、システムのソフトウェア機能とマシンの構成を記述できます。 生成の結果は 完全版 OS。 生成されたOSバージョンは、モジュールとデータのシステムセットのコレクションです。

4.) 機能的冗長性の原則：この原則は、同じ作業を異なる方法で実行する可能性を考慮に入れています。 OSには、いくつかのタイプのモニター（1つまたは別のタイプのリソースを制御するスーパーバイザーモジュール）、コンピューティングプロセス間の通信を整理するさまざまな手段が含まれる場合があります。 いくつかのタイプのモニター、いくつかのファイル管理システムの存在により、ユーザーはOSをコンピューティングシステムの特定の構成に迅速かつ最も適切に適合させ、特定のクラスの問題を解決するときにハードウェアの最も効率的なロードを保証し、最大限に活用することができます特定のクラスの問題を解決するときのパフォーマンス。

5.) 仮想化の原則：仮想リソースの構築、それらの配布および使用は、現在、ほとんどすべてのOSで使用されています。 この原則により、システムの構造を特定のプロセススケジューラーとリソースアロケーター（モニター）のセットの形式で表現し、単一の集中型リソース割り当てスキームを使用できます。

仮想性の概念の最も自然で完全な現れは概念です 仮想マシン ..。 ユーザーに提供される仮想マシンは、実際のマシンのアーキテクチャーを再現しますが、この表現のアーキテクチャー要素は、原則としてシステムでの作業を簡素化する、新しいまたは改善された特性を生み出します。 特性は任意ですが、ほとんどの場合、ユーザーは次の構成でアーキテクチャ特性の観点から独自の「理想的な」マシンを持ちたいと考えています。

-動作ロジックの点で均一な、実質的に無制限のボリュームの仮想メモリ。

-並列に動作し、動作中に相互作用できる任意の数の仮想プロセッサ。

-これらのデバイスの動作を開始する1つまたは別の仮想プロセッサの動作に関して、仮想マシンのメモリを並列または順次、非同期または同期で操作できる任意の数の外部仮想デバイス。

仮想化の側面の1つは、他のOS用に開発された特定のOSアプリケーションで実行する機能の編成です。 言い換えれば、私たちはいくつかの動作環境を組織化することについて話しているのです。

6.) プログラムの外部デバイスからの独立性の原則：この原則は現在、圧倒的多数の汎用オペレーティングシステムに実装されています。 初めて、この原則はUNIXOSで最も一貫して実装されました。 また、最新のPCオペレーティングシステムのほとんどに実装されています。 この原則は、番組と特定のデバイスとの接続が、番組を放送するレベルではなく、その実行の計画期間中に実行されるという事実にあります。 その結果、データが配置されている新しいデバイスでプログラムを実行している場合、再コンパイルは必要ありません。

7.) 互換性の原則：互換性の側面の1つは、他のOSまたはこのOSの以前のバージョン、および別のハードウェアプラットフォーム用に作成されたプログラムを実行するOSの機能です。 質問を分ける必要があります バイナリ互換性と ソースの互換性アプリケーション。

バイナリ互換性は、実行可能プログラムを取得して別のOSで実行できる場合に実現されます。 これには、プロセッサ命令のレベルでの互換性、システムコールのレベルでの互換性、さらには動的にリンクされている場合はライブラリコールのレベルでの互換性が必要です。

ソースの互換性には、システムソフトウェアの適切なトランスレータ、およびライブラリとシステムコールの互換性が必要です。 この場合、既存のソーステキストを新しい実行可能モジュールに再コンパイルする必要があります。

異なるアーキテクチャに基づくプロセッサ間でバイナリ互換性を実現することは、はるかに困難です。 あるコンピュータが別のコンピュータのプログラムを実行するためには（たとえば、IBM PCなどのPC用のプログラムは、Apple MacintoshなどのPCで実行することが望ましい）、このコンピュータは、最初は動作しないマシン命令で動作する必要があります。理解する。 この場合、680x0プロセッサ（またはPowerPC）を実行する必要があります バイナリコード i80x86プロセッサ用に設計されています。 80x86プロセッサには、独自の命令デコーダ、レジスタ、および内部アーキテクチャがあります。 680x0プロセッサは80x86バイナリを理解しないため、各コマンドを選択し、デコードして次のことを判断する必要があります。

意図したことを実行してから、680×0用に記述された同等のサブルーチンを実行します。

ソフトウェアとユーザーインターフェイスの互換性を確保する手段の1つは、POSIX標準への準拠です。これを使用すると、UNIXスタイルのプログラムを作成でき、後でシステム間で簡単に移植できます。

8.) オープン性とスケーラビリティの原則：オープンオペレーティングシステムは、コンピューティングシステムを保守するユーザーとシステムスペシャリストの両方による分析に利用できます。 拡張可能な（変更可能で開発された）OSは、生成機能を使用できるだけでなく、その構造に新しいモジュールを導入したり、既存のモジュールを改善したりすることもできます。 つまり、システムの整合性を損なうことなく、必要に応じて簡単に追加や変更を行うことができるはずです。 マイクロ核技術を使用してオペレーティングシステムを構築するためのクライアントサーバーアプローチは、拡張の優れた機会を提供します。 このアプローチに従って、OSは、特権制御プログラムのセットと非特権サービス（サーバー）のセットとして構築されます。 OSの主要部分は変更されていませんが、同時に新しいサーバーを追加したり、古いサーバーを改善したりすることができます。 この原則は時々次のように解釈されます システムの拡張性.

9.) モビリティの原則：オペレーティングシステムは比較的持ち運びが簡単でなければなりません

あるタイプのプロセッサから別のタイプのプロセッサに接続し、あるタイプのハードウェアプラットフォームから、プロセッサのタイプとすべてのコンピュータハードウェア（コンピューティングシステムアーキテクチャ）を編成する方法とともに、別のタイプのハードウェアプラットフォームに接続します。 移植性の原則は互換性の原則に非常に近いことに注意してください。ただし、それらは同じものではありません。 ポータブルOSを作成することは、ポータブルコードを作成することと似ていますが、従うべきことがいくつかあります。 ルール：

-ほとんどのOSは、後で移植する予定のすべてのシステムで使用できる言語で実行する必要があります。 これは、まず第一に、OSがその言語で書かれなければならないことを意味します 上級、好ましくは、例えばＣで標準化されている。アセンブリで書かれたプログラムは、一般に移植可能ではない。

-ハードウェアと直接対話するコードの部分を最小限に抑えるか、可能であれば除外することが重要です。 ハードウェアへの依存はさまざまな形をとることができます。 依存関係の明らかな形式には、レジスタやその他のハードウェアの直接操作が含まれます。 最後に、ハードウェアに依存するコードを完全に除外できない場合は、適切にローカライズされたいくつかのモジュールに分離する必要があります。 ハードウェアに依存するコードをシステム全体に配布する必要はありません。 たとえば、プログラム可能な抽象データ型でハードウェアに依存する構造を非表示にすることができます。

POSIX標準の導入は、作成されたソフトウェアの移植性を確保することを目的としていました。

10.) コンピューティングセキュリティの原則：計算上のセキュリティを確保することは、マルチユーザーシステムにとって望ましい機能です。 セキュリティルールは、あるユーザーのリソースを他のユーザーから保護したり、リソースクォータを設定して、1人のユーザーがメモリなどのすべてのシステムリソースを乗っ取らないようにするなどのプロパティを定義します。

不正アクセスから情報を確実に保護することは、ネットワークオペレーティングシステムの必須機能です。

—————————————————————

何POSIX: コンピュータ環境用のプラットフォームに依存しないシステムインターフェイスPOSIX（コンピュータ環境用のポータブルオペレーティングシステムインターフェイス）はIEEE標準（電気電子学会）であり、シェル、ユーティリティ、ツールキットなどのオープンオペレーティングシステムのシステムインターフェイスについて説明しています。 さらに、POSIXは、セキュリティタスク、リアルタイムタスク、管理プロセス、ネットワーク機能、およびトランザクション処理を標準化します。 この標準はUNIXシステムに基づいていますが、他のオペレーティングシステムにも実装できます。 POSIXは、世界中での試みとして始まりました 有名な組織 IEEEは、プラットフォームに依存しない抽象的な標準を開発することにより、UNIX環境でのアプリケーションの移植性を促進します。 たとえば、よく知られているリアルタイムOS QNXは、この規格の仕様に準拠しています。

この規格では、仮想メモリシステムVMS（仮想メモリシステム）、MPE（マルチプロセス実行）マルチタスク、およびCTOS（オペレーティングシステムによって生成された収束テクノロジ...）について詳しく説明しています。 したがって、POSIXは、実際にはPOSIX.I –POSIX.12と呼ばれる一連の標準です。 POSIX.1はCを主要言語として想定していることにも注意してください。

APIシステム関数の記述言語。

したがって、これらの標準に従って作成されたプログラムは、すべてのPOSIX準拠システムで同じように実行されます。 ただし、場合によっては、標準は本質的に助言にすぎません。 一部の規格は非常に厳密に説明されていますが、他の部分は基本的な要件を表面的にしか明らかにしていません。

POSIXAPIのオペレーティングシステムの実装は異なります。 UNIXシステムの大部分が最初にIEEE標準1003.1-1990仕様に準拠している場合、WinAPIはPOSIXに準拠していません。 ただし、MS Windows NTオペレーティングシステムでこの標準をサポートするために、ユーザープロセスの特権レベルで動作する特別なPOSIXAPIサポートモジュールが導入されました。

このモジュールは、ユーザープログラムからシステムカーネルへの呼び出しの変換と転送を提供し、WinAPIを介してカーネルを操作します。 WinAPIを使用して構築された他のアプリケーションは、標準のI / Oストリームメカニズム（stdin、stdout）を介してPOSIXアプリケーションに情報を渡すことができます。

関連する記事はありません ...