デバイスファイル

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ

Unix ライクな オペレーティング システムではデバイス ファイルまたは特殊ファイル、通常のファイルのようにファイル システムに表示されるデバイス ドライバへのインターフェイスです。DOSOS/2、およびWindowsにも特殊ファイルがありますこれらの特殊ファイルにより、アプリケーション プログラムは、標準入出力システム コールを介してデバイス ドライバを使用してデバイスと対話できます標準システム コールを使用すると、多くのプログラミング タスクが簡素化され、デバイスの特徴や機能に関係なく、一貫したユーザー空間 I/O メカニズムが実現します。

概要

通常、デバイス ファイルは、標準デバイス (プリンターやシリアル ポートなど) への単純なインターフェイスを提供しますが、ディスク パーティションなど、これらのデバイス上の特定の固有のリソースにアクセスするためにも使用できますさらに、デバイス ファイルは、データ シンク乱数ジェネレーターなど、実際のデバイスとは関係のないシステム リソースにアクセスする場合にも役立ちます

Unix ライクなオペレーティング システムには、キャラクタ スペシャル ファイルブロック スペシャルファイルとして知られる 2 種類のデバイス ファイルがありますこれらの違いは、オペレーティング システムとハードウェアによって読み書きされるデータの量にあります。デバイスに接続されていないが、通常のファイルでもない 名前付きパイプとは対照的に、これらをまとめてデバイス スペシャル ファイルと呼ぶことができます。

MS-DOSは、特殊ファイルの概念を Unix から借用しましたが、名前をdevicesに変更しました。[1] MS-DOS の初期のバージョンはディレクトリ階層をサポートしていなかったため、デバイス名を予約語することで通常のファイルと区別しましたCONこれらは、 CP/Mとのある程度の互換性のために選択されたもので、下位互換性のために最新の Windows にまだ存在しています。

一部の Unix ライクなシステムでは、ほとんどのデバイス ファイルは、伝統的に にマウントされている仮想ファイル システムの一部として管理され/dev、実行時にハードウェアの追加と削除を監視する制御デーモンに関連付けられている可能性がありますカーネルによって自動的に行われるわけではなく、システムまたはユーザー空間でスクリプトを呼び出して、特別なデバイスのニーズを処理する可能性があります。FreeBSDDragonFly BSDおよびDarwinには、専用のファイル システムdevfsがあります。デバイス ノードは、このファイル システムによってカーネル空間で自動的に管理されます。Linux にも同様のdevfsがありました実装されていましたが、後に放棄され、バージョン 2.6.17 以降で削除されました。[2] Linux は現在、主にudevとして知られるユーザー空間の実装を使用していますが、多くのバリアントがあります。

Solaris コンテナなど、chrootプロセスの分離をサポートする Unix システムでは、通常、各 chroot 環境には独自の が必要です。これらのマウント ポイントは、ホスト OS のグローバル ファイル システム ツリーのさまざまなノードに表示されます。の chroot インスタンスに取り込まれるデバイス ノードを制限することにより、chroot 環境によってハードウェアの分離を強制できます (プログラムは、表示も名前も指定できないハードウェアに干渉することはできません。これは、Unixファイル システムのアクセス許可よりもさらに強力なアクセス制御の形式です)。 /dev/dev

MS-DOS は、各デバイス ファイルを排他的に開くことにより、ハードウェア デバイスの競合 ( TSRを参照) を管理しました。すでに使用されているデバイスにアクセスしようとするアプリケーションは、デバイス ファイル ノードを開くことができないことを発見します。Unix と Linux では、同時アクセスに関してさまざまなデバイス ドライバセマンティクスが実装されています[3]

Unix および Unix ライクなシステム

Linux カーネルの単純化された構造。ファイル システムは、I/O サブシステムの一部として実装されます。

デバイス ノードは、オペレーティング システムのカーネルが既に割り当てているリソースに対応します。Unix はこれらのリソースをメジャー番号マイナー番号[4]で識別し、どちらもノードの構造の一部として保存されますこれらの番号の割り当ては、さまざまなオペレーティング システムやさまざまなコンピューター プラットフォームで一意に行われます。一般に、メジャー番号はデバイス ドライバを識別し、マイナー番号はドライバが制御する特定のデバイス (おそらく多数の中から) を識別します: [5]この場合、システムはマイナー番号をドライバに渡します。ただし、動的番号割り当てが存在する場合、これは当てはまらない場合があります (たとえば、FreeBSD 5 以降)。

他の特殊なファイル タイプと同様に、コンピュータ システムは標準のシステム コールを使用してデバイス ノードにアクセスし、それらを通常のコンピュータ ファイルのように扱います。2 つの標準タイプのデバイス ファイルが存在します。残念ながら、それらの名前は歴史的な理由から直観に反するものであり、その結果、2 つの違いの説明はしばしば正しくありません。

キャラクターデバイス

キャラクタ スペシャル ファイルまたはキャラクタ デバイスは、ハードウェア デバイスへのバッファなしの直接アクセスを提供します。プログラムが一度に 1 文字ずつ読み書きできるとは限りません。それは問題のデバイス次第です。たとえば、ハード ディスクのキャラクタ デバイスでは、通常、すべての読み取りと書き込みをブロック境界に揃える必要があり、1 バイトの読み取りは許可されません。

キャラクターデバイスは、ブロックベースのハードウェアの一部のキャラクターデバイスでは通常、アライメントされたブロックを読み書きするプログラムが必要であるという事実にまつわる混乱を避けるために、 raw デバイスと呼ばれることがあります。

ブロックデバイス

ブロック スペシャル ファイルまたはブロック デバイスは、ハードウェア デバイスへのバッファリングされたアクセスを提供し、それらの仕様からの抽象化を提供します。[6]キャラクター デバイスとは異なり、ブロック デバイスでは常に、プログラマは任意のサイズ (単一の文字/バイトを含む) および任意の配置のブロックを読み書きできます。欠点は、ブロック デバイスはバッファリングされるため、書き込まれたデータがカーネルのバッファから実際のデバイスに渡されるまでにかかる時間や、2 つの個別の書き込みが物理デバイスに到達する順序がプログラマにはわからないことです。さらに、同じハードウェアがキャラクター デバイスとブロック デバイスの両方を公開する場合、キャラクター デバイスを使用するクライアントがブロック デバイスのバッファーで行われた変更を認識しないため、データが破損する危険性があります。

ほとんどのシステムは、ハード ディスクなどのハードウェアを表すブロック デバイスとキャラクター デバイスの両方を作成します。FreeBSD と Linux は特にそうではありません。前者はブロック デバイスのサポートを削除しましたが[7]、後者はブロック デバイスのみを作成します。Linux でディスク用のキャラクター デバイスを取得するには、「raw」ドライバーを使用する必要がありますが、Linux 固有のO_DIRECTフラグ を使用してブロック デバイスを開くことで、キャラクター デバイスを開くのと同じ効果が得られます。

疑似デバイス

Unix ライクなシステムのデバイス ノードは、必ずしも物理デバイスに対応している必要はありません。この対応がないノードは、疑似デバイスのグループを形成します。これらは、オペレーティング システムによって処理されるさまざまな機能を提供します。最も一般的に使用される (文字ベースの) 疑似デバイスには、次のものがあります。

さらに、 ioctlインターフェイスを備えた BSD 固有の疑似デバイスには、次のものも含まれる場合があります。

ノードの作成

ノードはmknodシステム コールによって作成されます。ノードを作成するためのコマンドライン プログラムは、 mknodとも呼ばれます。ノードは、通常のファイルシステム システム コール ( renameunlink ) およびコマンド( mvrm ) によって移動または削除できます。

一部の Unix バージョンには、ディレクトリ/devに必要なすべてのデバイスを作成するためのmakedevまたはMAKEDEVという名前のスクリプトが含まれています。これは、デバイスにメジャー番号が静的に割り当てられているシステムでのみ意味があります (たとえば、カーネル モジュールでハードコーディングすることによって)。

FreeBSDなどの他の一部の Unix システムでは、devfs のみを介してカーネルベースのデバイス ノード管理を使用し、手動ノード作成をサポートしていませんでした。POSIX との互換性を維持するためにmknod(2)システム コールとmknod(8)コマンドが存在しますが、devfs の外部で手動で作成されたデバイス ノードはまったく機能しません。[9]

命名規則

次のプレフィックスは、デバイスのタイプを識別するために、/dev階層 内の一部のデバイスの名前に使用されます。

一部のオペレーティング システムでは、いくつかの追加のプレフィックスが一般的に使用されるようになりました。

  • fb :フレームバッファ
  • fd : (プラットフォーム)フロッピー ディスク。ただし、この同じ略語は、ファイル記述子を参照するためにも一般的に使用されます。
  • hd : (「クラシック」) IDEドライバー (以前は ATAハードディスク ドライブ、ATAPI光学ディスク ドライブなどに使用されていました)
    • hda : 最初のATA チャネルのマ​​スター デバイス(通常、メジャー番号 3 とマイナー番号 0 で識別されます)
    • hdb : 最初の ATA チャネルのスレーブ デバイス
    • hdc : 2 番目の ATA チャネルのマ​​スター デバイス
    • hdd : 2 番目の ATA チャネルのスレーブ デバイス
  • parportpp :パラレル ポート
  • mem :メインメモリ(キャラクターデバイス)
  • NVMeドライバー:
    • nvme0 : 最初に登録されたデバイスのデバイス コントローラ (キャラクター デバイス)
    • nvme0n1 : 最初に登録されたデバイスの最初の名前空間 (ブロック デバイス)
    • nvme0n1p1 : 最初に登録されたデバイスの最初の名前空間の最初のパーティション (ブロック デバイス)
  • MMCドライバー:
    • mmcblk : MMCメディア ( SDカード、ラップトップの eMMC チップなど) 用のストレージ ドライバー
      • mmcblk0 : 最初に登録されたデバイス
      • mmcblk0p1 : 最初に登録されたデバイスの最初のパーティション
  • libATA (最新のPATA / SATAドライバー)、USBIEEE 1394などでも使用されるSCSIドライバー:
    • sd : 大容量記憶装置ドライバー (ブロックデバイス)
      • sda : 最初に登録されたデバイス
      • sdb、sdcなど: 2 番目、3 番目などの登録済みデバイス
    • ses : エンクロージャードライバー
    • sg : 汎用 SCSI レイヤー
    • sr : 「ROM」ドライバー (データ指向の光学ディスク ドライブ。 scd は単なる 2 次エイリアス)
    • st :磁気テープドライバー
  • tty :端末
    • ttyS : (プラットフォーム)シリアルポートドライバー
    • ttyUSB : USB シリアルコンバーター、モデムなど。

Linux で使用されるプレフィックスの正規のリストは、Linux デバイス リスト、Linux オペレーティング システムの割り当てられたデバイス番号および/devディレクトリ ノードの公式レジストリにあります。[10]

ほとんどのデバイスでは、このプレフィックスの後に、特定のデバイスを一意に識別する番号が続きます。ハードドライブの場合、デバイスを識別するために文字が使用され、その後にパーティションを識別する番号が続きますしたがって、ファイルシステムは、たとえば/dev/sda3としてディスク上の領域を「認識する」か、 /dev/pts/14に関連付けられたネットワーク端末セッションを「認識する」ことができます。

典型的な PCマスター ブート レコードを使用するディスクでは、プライマリ パーティションとオプションの拡張パーティションのデバイス番号は 1 から 4 までの番号が付けられますが、論理パーティションのインデックスは以前のパーティションのレイアウト (親の拡張パーティション) に関係なく 5 以降です。パーティションはディスクの 4 番目のパーティションである必要はなく、4 つのプライマリ パーティションすべてが存在する必要もありません)。

通常、デバイス名は異なる Unix ライクなシステム バリアント間では移植できません。たとえば、一部のBSDシステムでは、IDE デバイスの名前は/dev/wd0/dev/wd1などです。

devfs

devfsは、Unix ライクなオペレーティング システム上のデバイス ファイル システムの特定の実装であり、デバイス ファイルを表示するために使用されます。実装の基本的なメカニズムは、OS によって異なる場合があります。

これらの特別なファイルを、ハード ドライブなどの物理的に実装されたファイル システムに維持するのは不便であり、とにかくカーネルの支援が必要であるため、物理的に保存されない特別な目的の論​​理ファイル システムのアイデアが生まれました。

デバイスがいつ表示される準備ができているかを定義することは簡単ではありません。devfs アプローチは、デバイス ドライバーが有効化および無効化するデバイスに関連する devfs エントリの作成および削除を要求することです。

PC DOS、TOS、OS/2、および Windows

デバイス ファイルは、特定のポートやデバイスへのアクセスを許可するために 、 PC DOSTOSOS/2、およびWindowsシステムで使用される予約済みのキーワードです。

MS-DOSは、特殊ファイルの概念を Unix から借用しましたが、名前をdevicesに変更しました。[1] MS-DOS の初期のバージョンはディレクトリ階層をサポートしていなかったため、デバイス名を予約語にすることで、デバイスを通常のファイルと区別していましたこれは、特定のファイル名がデバイス用に予約されていることを意味し、新しいファイルやディレクトリの名前には使用しないでください。[11]予約済みの名前自体は、 CP/MPIPでのコマンド の「特殊ファイル」処理と互換性があるように選択されましたDOS には 2 種類のデバイスがありました。ブロック デバイス (ディスク ドライブに使用) とキャラクター デバイス (通常、COM および PRN デバイスを含む他のすべてのデバイス) です。[12]

DOS はデバイス ファイルを使用して、プリンタとポートにアクセスします。Windows のほとんどのバージョンにはこのサポートも含まれており、特定の名前のファイルやフォルダーを作成しようとすると、これらの名前を持つことができないため、混乱を招く可能性があります。[13] MS-DOSのバージョン 2.x はAVAILDEV CONFIG.SYSパラメータを提供します。これを に設定するFALSEと、これらの特別な名前は、接頭辞が\DEV\. [14]

Atari TOSの DOS に似た部分であるGEMDOSは、DOSと同様のデバイス名をサポートしていましたが、DOS とは異なり、通常のファイル名ではなくデバイスとして識別するために末尾に「:」文字 (DOS ではこれはオプションです) が必要でした (したがって、「 CON:" は DOS と TOS の両方で機能しますが、"CON" は TOS では通常のファイルを指定しますが、DOS ではコンソール デバイスを指定します)。MiNTおよびMagiCでは、「U:」ドライブ文字を介してアクセスされる特殊な UNIX ライクな統合ファイルシステム ビューも、デバイス ファイルを「U:\DEV」に配置しました。

デバイスキーワード[13] 入力として使用 出力として使用
コン ^ Z (Ctrl-Z) が押される まで、入力されたデータを受け取ります。 データをコンソールに出力します。
PRN [15] テキストをプリンターに出力します。通常はLPT1またはLSTにリダイレクトされます。他のデバイスに再構成可能な場合もあります。[16] [17] [18]
AUX (OS/2 [15]にはありません) 補助デバイス (通常はCOM1などのシリアル デバイス) からデータを読み取ります。他のデバイスに再構成可能な場合もあります。[16] [17] [18] 補助デバイス (通常はCOM1などのシリアル デバイス) にデータを送信します他のデバイスに再構成可能な場合もあります。[16] [17] [18]
ヌル null またはデータなしを返します。 受信データを破棄します。
CLOCK$ (MS-DOS 2.11 [19] [16] [17]のいくつかのバージョンではまだCLOCKという名前)
KEYBD$ (マルチタスク MS-DOSのみ) ? ?
KBD$ ( OS/2 [15]のみ) ? ?
SCREEN$ (マルチタスク MS-DOS および OS/2 [15]のみ) ? ?
POINTER$ (OS/2 [15]のみ) ? ?
MOUSE$ (OS/2 [15]のみ) ? ?
$IDLE$ ( DR-DOS (5.0 以降) およびマルチユーザー DOS ( Concurrent DOS 386以降) ファミリーのみ)
CONFIG$ (MS-DOS 7.0 以降のみ)
LST ( 86-DOSおよび DOS 1.x のみ、 HP Portable Plus用の Hewlett-Packard の MS-DOS 2.11 にも[16] [17] ) データを返しません。 ラインプリンターにデータを送信します。(Hewlett-Packard の MS-DOS 2.11 用の LPT2 [16] [17] )
PLT (Hewlett-Packard のHP Portable Plus用 MS-DOS 2.11 のみ[16] [17] ) データを返しません。 割り当てられたプロッターにデータを送信します。接続されたプロッタ デバイスは再構成可能です。[16] [17]
LPT1LPT2LPT3、場合によってはLPT4 (DR-DOS 7.02 以降およびマルチユーザー DOS の一部のバージョン) 選択したパラレル ポートにデータを送信します。
COM1COM2COM3COM4 選択したシリアル ポートからデータを読み取ります。 選択したシリアル ポートにデータを送信します。
82164A ( HP Portable Plus用の Hewlett-Packard の MS-DOS 2.11 のみ[16] [17] ) COM2 にリダイレクトします。 COM2 にリダイレクトします。

シェルのリダイレクトとパイプを使用して、デバイスとの間でデータを送受信できます。たとえば、次のように入力すると、ファイルc:\data.txtがプリンターに 送信されます。

TYPE c:\data.txt > PRN

PIPE、MAILSLOT、および MUP は、その他の標準的な Windows デバイスです。[20]

IOC

PC-E500PC-E500Sなどのシャープの ポケット コンピュータの 8 ビット オペレーティング システムはBASICインタープリタ、初歩的な12 ビット FATに似たファイルシステムを実装する DOS 2 に似たファイル コントロール システム (FCS) 、およびSTDO :/ SCRN : (ディスプレイ)、STDI:/KYBD: (キーボード)、COM: (シリアル I/O)、STDL:/PRN: (プリンター)、CAS: (カセットテープ)、E:/F:/G: (メモリーファイル)、S1:/S2:/S3: (メモリーカード)、X: /Y: (フロッピー)、SYSTM: (システム)、および NIL: (機能)。[21]

実装

オペレーティング·システム ファイルシステムまたは管理ソフトウェア 標準マウントポイント 著者 ノート
Linux 2.3.46pre5–2.6.17 devfs [22]devfsd /dev リチャード・グーチ ユーザー空間でデバイス ノード イベントを処理するオプションのデーモンdevfsdを使用して、カーネルに完全に実装されています。[23]廃止 – ユーザーはudevおよび/またはdevtmpfsに移行することをお勧めします。
Linux 2.5– 任意の fs 上のudev、ただし通常はtmpfs /dev Greg Kroah-HartmanKay SieversDan Stekloff 主にユーザー空間に実装され、デバイス情報はsysfsから収集されます。デバイス ファイルは、従来の汎用ファイル システム、またはメモリ ファイル システム ( tmpfs ) に格納できます。
Linux 2.6.32– udev の有無にかかわらず devtmpfs /dev ケイ・シーバース、ジャン・ブランク、グレッグ・クロア=ハートマン udev が初めて実行される前にノードを提供するデバイス ファイルシステムのハイブリッド カーネル/ユーザー空間アプローチ[24]
ソラリス devfs [25] /devices サン・マイクロシステムズ Solaris-2.1 で動的にロードされるドライバーで導入されました。
FreeBSD 2.0– devfs /dev ポール・ヘニング・カンプ カーネルに完全に実装されています。
ドラゴンフライBSD 2.3.2– devfs /dev アレックス・ホーナング カーネルに完全に実装されています。
マックOS devfs /dev アップル社。 カーネルに完全に実装されています。
HP-UX B.11.31 devfs /dev HP カーネルに完全に実装されています。
プラン9 # ベル研究所 カーネルに実装されています。
RISC OS デバイスFS Devices: どんぐりコンピュータ DeviceFS は 1991 年に開始され[26]、RISC OS 3 で初めて登場しました。これは、いくつかのデバイスを特別なファイルのように管理します。最も一般的なのは、パラレル、シリアル、FastParallel、および USB です。SystemDevices モジュールは、Vdu、Kbd、Null、および Printer などの疑似デバイスを実装します。
MS-DOSPC DOSDR-DOS 太い \DEV(および/DEV) 様々 カーネルに実装されているように、キャラクター デバイスは仮想 \DEV ディレクトリと任意のディスク ディレクトリに表示されます。MS-DOS/PC DOS 2.x では、CONFIG.SYS AVAILDEV =FALSE ディレクティブを使用して、デバイスが \DEV にのみ存在するように強制できます。
MagicMiNTMultiTOS U:\DEV[27] [28] Application Systems Heidelberg、Eric R. Smith、Atari Corp. 特別な U: ドライブには仮想 DEV ディレクトリが含まれており、その中にデバイス ファイルを見つけることができます。
Windows 9x \\devices\ マイクロソフト
WindowsNT \Device マイクロソフト \Deviceディレクトリは、Windows NT オブジェクトの名前空間の一部です
Windows NT Win32 サブシステム \\.\ マイクロソフト この\\.\プレフィックスにより、サポート API は Win32 ファイルの名前空間ではなく、Win32 デバイスの名前空間にアクセスできるようになります。Win32 デバイス名は、Windows NT\Deviceディレクトリ下のデバイス名へのシンボリック リンクです。

も参照

参考文献

  1. ^ a b "Windows for Workgroups: VSHARE.386 がファイル共有を管理する方法" . Support.microsoft.com。1999-09-22 . 2014 年1 月 22 日閲覧
  2. ^ Kroah-Hartman、グレッグ (2005-06-20). "[PATCH] devfs: カーネル ツリーから devfs を削除します" . Linux カーネル ソース ツリー2021年6月12日閲覧
  3. ^ コーベット、ジョナサン。Kroah-Hartman、グレッグ。ルビーニ、アレッサンドロ(2005)。「デバイスファイルのアクセス制御」. Linux デバイス ドライバー、第 3 版オライリー2017年 4 月28 日閲覧シングル オープン デバイスの次のステップは、1 人のユーザーが複数のプロセスでデバイスを開くことができるようにすることですが、一度に 1 人のユーザーだけがデバイスを開くことを許可します。
  4. ^ カーニハン、ブライアン W .; パイク、ロブ(1984)。UNIX プログラミング環境プレンティスホールp。 66 . ISBN 0-13-937681-X.
  5. ^ ニール・ブラウン (2010-10-27). 「過去の Unix の亡霊: デザイン パターンの歴史的調査」 . Linux ウィークリー ニュース2014 年3 月30 日閲覧
  6. ^ "IEEE Std 1003.1、2013 年版" . 2014 年4 月 24 日閲覧
  7. ^ "FreeBSD アーキテクチャ ハンドブック" . 2013 年3 月 7 日閲覧
  8. ^ "usr.sbin/envstat/envstat.c" . BSDクロスリファレンスNetBSD . 2021 年 11 月。
  9. ^ "mknod(8)" . FreeBSD マニュアルページ. FreeBSD プロジェクト。2016-10-03 . 2021年6月12日閲覧
  10. ^ Linux Assigned Names and Numbers Authority (2009-04-06). 「Linux 割り当てデバイス (2.6 以降のバージョン)」 . Linux カーネル(Documentation/devices.txt)2016-04-24のオリジナルからのアーカイブ2013 年6 月 8 日閲覧
  11. ^ 「NT デバイス名である Macintosh ファイル名を作成しないでください」 . Support.microsoft.com。2006-11-01 . 2014 年1 月 22 日閲覧
  12. ^ 「デバイス属性」 . Stanislavs.org . 2014 年1 月 22 日閲覧
  13. ^ a b "MS-DOS デバイス ドライバ名はファイル名として使用できません" . リビジョン 2.0。マイクロソフト2003-05-12。KB74496、Q74496。2012-07-21のオリジナルからのアーカイブ。
  14. ^ 「文書化されていないコマンド」 . 4dos.info . ケブトロニクス。2002-04-12 . 2014 年5 月 16 日閲覧
  15. ^ a b c d e f IBM オペレーティング システム/2 テクニカル リファレンス - プログラミング ファミリー(PDF)巻。1 (第 1 版)。IBM1987 年 9 月 [1986 年]。2017-01-03 のオリジナルからアーカイブ(PDF) 。
  16. ^ a b c d e f g h i Hewlett-Packard - Technical Reference Manual - Portable PLUS (1 ed.)。米国オレゴン州コーバリス: Hewlett-Packard Company , Portable Computer Division. 1985 年 8 月。45559-90001 2016 年11 月 27 日閲覧
  17. ^ a b c d e f g h i Hewlett-Packard - Technical Reference Manual - Portable PLUS (PDF) (2 ed.)。米国オレゴン州コーバリスのポータブル コンピュータ部門: Hewlett-Packard Company1986 年 12 月 [1985 年 8 月]。45559-90006。2016-11-28 のオリジナルからのアーカイブ(PDF) 2016 年11 月 27 日閲覧
  18. ^ a b c Paul, Matthias R. (1997-10-02). "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT" . 2003-10-04にオリジナルからアーカイブ2009 年3 月 29 日閲覧 [1]
  19. ^ パターソン、ティムマイクロソフト (2013-12-19) [1983]。"Microsoft DOS V1.1 および V2.0: /msdos/v20source/SKELIO.TXT, /msdos/v20source/HRDDRV.ASM" . コンピュータ歴史博物館マイクロソフト2014 年3 月25 日閲覧(注: 出版社はこれが MS-DOS 1.1 および 2.0 であると主張していますが、実際にはSCP MS-DOS 1.25であり、Altos MS-DOS 2.11TeleVideo PC DOS 2.11が混在しています。)
  20. ^ "REG: CurrentControlSet エントリ パート 2: SessionManager" . Support.microsoft.com。2006-11-01 . 2014 年1 月 22 日閲覧
  21. ^ テクニカル リファレンス マニュアル PC-E500 (PDF) . シャープ株式会社パーソナル機器事業部 情報システムグループ 1990 年 3 月。17. 2017-03-14 のオリジナルからアーカイブ(PDF) . 2017 年 3月14 日閲覧
  22. ^ グーチ、リチャード (2002-08-20). 「Linux Devfs (デバイス ファイル システム) FAQ」. 2021年6月13日閲覧
  23. ^ グーチ、リチャード. 「私の Linux への貢献」. 2021年6月13日閲覧Devfsd は、Linux Device Filesystem を使用してデバイス ノードの構成可能な管理を提供します。
  24. ^ "ドライバー コア: devtmpfs - カーネル管理の tmpfs ベースの /dev" . LWN . 2009 年 8 月10 日閲覧
  25. ^ "devfs(7FS)" . man ページのセクション 7: デバイスとネットワーク インターフェイスオラクル。2014 . 2021年6月12日閲覧
  26. ^ 「Project Black 変更ログ」. 2016 年5 月 15 日閲覧
  27. ^ 「ドライブ U: in MagicC」 . 2016-03-28。2017-01-15 のオリジナルからのアーカイブ2017 年 1月9 日閲覧
  28. ^ "FreeMiNT-Portal - mint.doc" . 2000-04-27。2017-01-15 のオリジナルからのアーカイブ2017 年 1月9 日閲覧

さらに読む