レンタルサーバ + Webシステム開発 = E-business

■レンタルサーバご利用参考資料
サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。

Linux JF(Japanese FAQ)Project.
JF は, Linux に関する解説文書・FAQ などを作成・収集・配布するプロジェクトです.

グリーンネット・トップページへ戻る


一覧に戻る
  Linux PCMCIA プログラマの手引き
  David Hinds, dhinds@allegro.stanford.edu
  v1.35, 1997/11/14 08:25:25
  Kazuyuki Okamoto, ikko-@pacific.rim.or.jp
  Hiroshi Kawashima (kei@sm.sony.co.jp)
  Hiro Sugawara, hiro@arkusa.com
  JF project
  v1.35, 1997/12/11 01:00:00

  この文書は Linux PCMCIA カードサービスインターフェースの為のカーネルデ
  バイスドライバの書き方を説明しています。また、カードサービスの利用者用
  ユーティリティの書き方も説明します。この文書(text,html,sgml) の最新は
  hyper.stanford.edu の /pub/pcmcia/doc にあります。 HTML 版は
  http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html にあります。
  ______________________________________________________________________

  目次

  1. 概説
     1.1 著作権表示と放棄声明
     1.2 謝辞

  2. 基本的な PCMCIA の概念
     2.1 PCMCIA ソケットインタフェース
     2.2 PCMCIA ソケット制御装置

  3. カードサービス関数解説
     3.1 クライアント管理関数
        3.1.1 RegisterClient
        3.1.2 DeregisterClient
        3.1.3 SetEventMask
        3.1.4 BindDevice
     3.2 ソケット状態管理
        3.2.1 GetStatus
        3.2.2 ResetCard
        3.2.3 SuspendCard
        3.2.4 ResumeCard
        3.2.5 EjectCard
        3.2.6 InsertCard
     3.3 入出力カードの設定関数
        3.3.1 RequestIO
        3.3.2 ReleaseIO
        3.3.3 RequestIRQ
        3.3.4 ReleaseIRQ
        3.3.5 RequestConfiguration
        3.3.6 ModifyConfiguration
        3.3.7 ReleaseConfiguration
        3.3.8 GetConfigurationInfo
     3.4 カード情報構造体 (CIS) 使用法
        3.4.1 GetFirstTuple, GetNextTuple
        3.4.2 GetTupleData
        3.4.3 ParseTuple
        3.4.4 ValidateCIS
     3.5 メモリ領域制御
        3.5.1 RequestWindow
        3.5.2 ModifyWindow
        3.5.3 MapMemPage
        3.5.4 ReleaseWindow
     3.6 大容量メモリサービス
        3.6.1 RegisterMTD
        3.6.2 GetFirstRegion, GetNextRegion
        3.6.3 OpenMemory
        3.6.4 CloseMemory
        3.6.5 ReadMemory, WriteMemory
        3.6.6 RegisterEraseQueue
        3.6.7 DeregisterEraseQueue
        3.6.8 CheckEraseQueue
     3.7 各種呼び出し
        3.7.1 GetCardServicesInfo
        3.7.2 AccessConfigurationRegister
        3.7.3 AdjustResourceInfo
        3.7.4 ReportError

  4. カード情報構造体 (CIS) の定義
     4.1 CIS タプルの定義
        4.1.1 CISTPL_CHECKSUM
        4.1.2 CISTPL_LONGLINK_A, CISTPL_LONGLINK_C, CISTPL_LINKTARGET, CISTPL_NOLINK
        4.1.3 CISTPL_LONGLINK_MFC
        4.1.4 CISTPL_DEVICE, CISTPL_DEVICE_A
        4.1.5 CISTPL_VERS_1
        4.1.6 CISTPL_ALTSTR
        4.1.7 CISTPL_JEDEC_C, CISTPL_JEDEC_A
        4.1.8 CISTPL_CONFIG
        4.1.9 CISTPL_CFTABLE_ENTRY
        4.1.10 CISTPL_MANFID
        4.1.11 CISTPL_FUNCID
        4.1.12 CISTPL_DEVICE_GEO
        4.1.13 CISTPL_VERS_2
        4.1.14 CISTPL_ORG
     4.2 CIS 構成レジスタ
        4.2.1 Configuration Option Register
        4.2.2 カードの構成情報と状態レジスタ
        4.2.3 ピン代替レジスタ
        4.2.4 ソケットとコピーレジスタ
        4.2.5 拡張状態レジスタ

  5. カードサービスイベントの扱いについて
     5.1 イベントハンドラの操作
     5.2 イベントの説明
     5.3 クライアントドライバのイベント操作の役割について

  6. メモリテクノロジドライバ
     6.1 MTD 要求の処理
     6.2 MTD 支援関数
        6.2.1 MTDRequestWindow, MTDReleaseWindow
        6.2.2 MTDModifyWindow
        6.2.3 MTDSetVpp
        6.2.4 MTDRDYMask

  7. ドライバサービスインタフェース
     7.1 他のクライアントドライバへのインタフェース
        7.1.1 dev_link_t 構造体
        7.1.2 register_pcmcia_driver
        7.1.3 unregister_pcmcia_driver
     7.2 ユーザモードの PCMCIA ユティリティとのインタフェース
        7.2.1 カードサービスのイベント通知
        7.2.2 ioctl の説明

  8. カードサービスクライアントドライバの解剖
     8.1 モジュールの初期化とリセット
     8.2 *_attach() と *_detach() 関数
     8.3 *_config() と *_release() 関数
     8.4 PCMCIA イベントハンドラ
     8.5 ロックと同期について
     8.6 現有の Linux のドライバで PCMCIA デバイスをアクセスする方法

  9. さらなる情報はどこにあるか?

  ______________________________________________________________________

  1.  概説

  Linux Kernel PCMCIA システムは 3 つの部分に分かれています。最下位のイ
  ンターフェースはソケットドライバです。次はカードサービスモジュールで
  す。特定のカード用のドライバはカードサービスの上位に位置しています。あ
  る特定のカードサービスクライアントはドライバサービスと呼ばれ、利用者用
  PCMCIA ユーティリティとカーネル PCMCIA 機能との間を結びます。

  ソケットドライバ層はソケットサービス API を大体利用しています。 2 つの
  ソケットドライバモジュールがあります。tcic モジュールは PCMCIA コント
  ローラの TCIC-2 系列のデータブックをサポートしています。i82365 モジュ
  ールは Intel i82365sl 系列と Cirrus, VLSI, Ricoh, Vadem チップのインテ
  ル互換のコントローラをサポートしています。

  カードサービスは PCMCIA パッケージの最も大きな単独の構成要素です。この
  サービスの API は DOS のカードサービスと似ており Unix 環境に適応してい
  ます。Linux への実装は Solaris PCMCIA のインターフェース仕様に準拠して
  います。この仕様は pcmcia_core モジュールに実装しています。バージョン
  2.1 の殆んどといくつかの PC Card 95 の仕様を実装しました。
  ドライバサービス層は PCMCIA ユーティリティから呼ばれるいくつかのカード
  サービス関数をアクセスする利用者用疑似ドライバとして実装しています。こ
  の実装は全ての PCMCIA クライアントドライバを見失わないようにするのと、
  物理ソケットとドライバを引き当てるのを確実にしています。ds モジュール
  内に実装しています。

  この文書はカードサービスとドライバサービスモジュールとドライバサービス
  へのユーザインターフェースのカーネルインターフェースについて説明してい
  ます。PCMCIA デバイスドライバの開発者の為に書いています。 Linux
  PCMCIA-HOWTO はどのように導入するかと Linux で PCMCIA をどのように使う
  かについて説明しています。この文書は cb-iris.stanford.edu の
  /pub/pcmcia にあります。

  1.1.  著作権表示と放棄声明

  Copyright (c) 1996, 1997 David A. Hinds

  この文書は著者の許可なしに如何なる形で複写または配布してかまいません。
  この文書を他の言語に翻訳など変更したものを含んで、変更点を明確に名乗っ
  て、この著作権表示をそのままに添付して自由に配布してください。

  私の同意無しに商用配布に利用可能です。必須ではありませんが、商用利用に
  あたり、私に通知して下さい。出版物に統合したいと思っている場合、最新の
  ものを使う必要がありますので私に連絡して下さい。

  この文書は明示的または暗黙的保証無しに``ありのまま''提供しています。こ
  の文書にある情報は御自身の責任で利用して下さい。

  1.2.  謝辞

  この PCMCIA ソフトウェアとドライバの開発のテストとデバッグを手伝ってく
  れた Linux ユーザの皆さんに感謝したいと思います。そしてカーネル開発を
  助けてくれた Linus Torvalds, Donald Becker, Alan Cox, と Bjorn Ekwall
  に感謝します。特に Solaris PCMCIA の実装について多くの助言となった打ち
  合せを行なった Michael Bender に感謝します。

  2.  基本的な PCMCIA の概念

  2.1.  PCMCIA ソケットインタフェース

  PCMCIA カードバスには 2 つの基本操作モードがあります。それは ``メモリ
  のみ''と``メモリと入出力''です。最初のモードは元々の第 1 版の仕様で定
  義されて単にメモリカードをサポートするものでした。次のモードは第 2 版
  で定義され、少しのメモリカードの制御信号が IO ポートと入出力割り込み信
  号を扱えるように再定義しています。

  PCMCIA カードは 2 つのメモリ空間があります。それは``属性メモリ''と
  ``一般メモリ''です。PCMCIA インタフェースはそれぞれの形式のメモリの
  16MB 以上のメモリを使えます。属性メモリは一般に種類の情報や構成するレ
  ジスタを保持するのに使用します。一般メモリはメモリカードの殆んどの領域
  か IO カードの場合はバッファ領域に使用します。PCMCIA 仕様 第2版に適合
  している全てのカードはカードがどのように構成されているかのカード情報構
  造(Card Information Structure (つまり ``CIS'')) を属性メモリに格納しま
  す。

  カードは分離制御信号を使って操作状況をホストに知らせます。この制御信号
  はカードの探知、レディ/ビジー状態、書き込み保護、電池不足と電池切れで
  構成しています。

  ``メモリと入出力''型のインターフェースモードのカードは 64K 以上の入出
  力ポートにアクセスできます。このモードでは入出力割り込みとカードの出力
  をホストシステムのスピーカへの経路を提供します。このモードではいくつか
  のメモリカード制御信号は特別な入出力カード信号を伝達するのにこれらのピ
  ンを使っているので使用できません。いくつかのカードでは制御信号を属性メ
  モリから特別な構成レジスタを読み出す代わりに用います。これを``ピン代替
  レジスタ''型のカードと呼びます。

  2.2.  PCMCIA ソケット制御装置

  PCMCIA 制御装置を PCMCIA カードとシステムバスの間の橋渡しをします。制
  御装置にはいくつかの種類がありますが、基本機能は同じです。ソケットサー
  ビス層は PCMCIA 制御装置を如何に扱うかの詳細を処理しています。

  PCMCIA 制御装置はホストメモリのジョブ空間と入出力空間のアドレス領域と
  カードのアドレス領域の割りつけを行ないます。全ての制御装置は最低 4つの
  独立したメモリ領域と2つの入出力領域をソケット毎に持っています。

  それぞれのメモリ領域はホストアドレス空間の基底アドレス、カード空間の基
  底アドレスとその領域の大きさで定義されます。いくつかの制御装置ではメモ
  リ領域の境界調整に違いがありますが、全ての制御装置は最低 4K 、且つその
  2 のべき乗の大きさのメモリ領域と基底アドレスで領域の倍数の大きさの領域
  をサポートしています。それぞれの領域を属性メモリか一般メモリを指すよう
  にプログラム出来ます。

  ホストアドレス上の入出力領域のアドレスがカード上に渡っても変更されない
  事がメモリ領域と異なっています。実際に、ホストとカードの領域の基底アド
  レスはいつも同じです。入出力領域は通常、境界調整が無いか大きさの制限は
  ありません。入出力領域の境界の始点と終点は 64K 内のバイト境界です。

  PCMCIA カードバスはカードから制御装置への一つの割り込み信号を定義しま
  す。制御装置はこの時適切なインラプト要求(IRQ) を操る役目を負います。全
  ての制御装置はカード入出力割り込みを空いている割り込みに割り当てます。
  従って制御装置はカード自身どの割り込みを使うか事前には分かりません。

  全ての PCMCIA 制御装置はカードが返す状態変更の割り込みを生成します。こ
  の割り込みは入出力カードが生成した入出力割り込みと区別され、別の割り込
  み線を使います。この信号はカードの検知、レディ/ビジー、書き込み保護、
  電池不足、電池切れを含んでいます。

  3.  カードサービス関数解説

  カードサービスは一般に次の形で呼びます。:

       #include "cs_types.h"
       #include "cs.h"

       int CardServices(int subfunc, void *arg1, void *arg2, ...);

  いくつかのカードサービス関数は #include 文を追加する必要があります。特
  殊な下位の関数は引数の数を認識します。CS_SUCCESS の戻り値は呼出が成功
  した事を示しています。その他の戻り値は失敗を示しています。

  3.1.  クライアント管理関数

  カードサービス関数を使うデバイスドライバを``クライアント''と呼びます。
  デバイスドライバは他のサービスを使用する前に RegisterClient を呼び出し
  てクライアントハンドルを取得しなければいけません。カードを抜く前にドラ
  イバを DeregisterClient を使用して抹消する必要があります。

  3.1.1.  RegisterClient

       int CardServices(RegisterClient, client_handle_t *client, client_reg_t *reg);

  client_reg_t データ構造体の定義は次のとおり:

       typedef struct client_reg_t {
               dev_info_t              *dev_info;
               u_long                  Attributes;
               u_long                  EventMask;
               int                     (*event_handler)(event_t event, int priority,
                                                       event_callback_args_t *args);
               event_callback_args_t   event_callback_args;
               u_long                  Version;
       } client_reg_t;

  RegisterClient はクライアントドライバとカードサービスの結合を確立しク
  ライアントに適切なソケットを接続します。 dev_info パラメタはソケットと
  関数をクライアントに合わせるのにカードサービスが使います。この対応を
  BindDevice を呼ぶ事を通してドライバサービスによって確立します。対応が
  確立したら、クライアントハンドルが client に返ります。

  次のフラグが属性に指定できます。:

     INFO_MASTER_CLIENT
        ドライバサービスクライアントだけが使用します。他に、ソケットから
        カードを抜いた時はクライアントが自動でなく解放しなければいけませ
        ん。

     INFO_IO_CLIENT
        クライアントが入出力カードドライバの場合に指定します。

     INFO_MEM_CLIENT
        クライアントがメモリテクノロジドライバの場合に指定します。

     INFO_MEM_CLIENT
        クライアントがメモリカードドライバの場合に指定します。

     INFO_CARD_SHARE
        互換性の為に入っています。何もしません。

     INFO_CARD_EXCL
        互換性の為に入っています。何もしません。

  EventMask はクライアントに何が起こっているか通知する時に指定します。
  event_handler の項目は EventMask で処理されるとカードサービスによって
  呼ばれます。event_handler_args 構造体はイベントハンドラに渡される構造
  体の雛型 (テンプレートr) です。Version パラメタはこのドライバが要求す
  るカードサービスのバージョンレベルを示します。これは現在無視されます。

  ドライバが RegisterClient を呼び出す前にカードサービスを扱う準備を行な
  う必要があります。この呼び出しはいつも CS_REGISTRATION_COMPLETE イベン
  トを生成し、ソケットが現在使用している場合は、わざと CS_CARD_INSERTION
  イベントを生成します。

  戻り値 :

     CS_OUT_OF_RESOURCE
        ドライバに必要な適切なドライバが見つかりません。

  3.1.2.  DeregisterClient

       int CardServices(DeregisterClient, client_handle_t client);

  DeregisterClient はクライアントとカードサービスの連結を行ないます。ク
  ライアントが割り当てられたリソースを解放した後で呼びます。連結が切れた
  ら、BindDevice を他のクライアントが呼ぶまで再確立出来ません。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

     CS_IN_USE
        クライアントに入出力ポート領域や割り込みなどのリソースが割り当て
        られているかソケット構成がロックされています。

  3.1.3.  SetEventMask

       int CardServices(SetEventMask, client_handle_t client, eventmask_t *mask);

  eventmask_t 構造体の定義は次のとおり:

       typedef struct eventmask_t {
               u_long          Attributes;
               u_long          EventMask;
       } eventmask_t;

  SetEventMask はクライアントに通知されたイベントを認識するようにマスク
  を更新します。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。
  3.1.4.  BindDevice

       int CardServices(BindDevice, bind_req_t *req);

  bind_req 構造体の定義は次のとおり:

       typedef struct bind_req_t {
               socket_t        Socket;
               u_char          Function;
               dev_info_t      *dev_info;
       } bind_req_t;

  BindDevice でデバイスドライバと適切なソケットを関係づけます。通常、新
  規に挿入されたカードが認識できた後でデバイスサービスから呼ばれます。一
  旦、ドライバがソケットと接続されると、そのソケットのクライアントととし
  てドライバを登録するのに適格でしょう。この呼び出しは引数がクライアント
  ハンドルではないことに注意して下さい。カードサービス呼び出しだけはソ
  ケット番号を引数に用いています。

  Function 変数はドライバに結合したい多機能カードのうちの機能 (複数可 )
  を指定します。Function 番号はカードの CISTPL_LONGLINK_MFC タプルに相当
  します。Function を BIND_FN_ALL に設定した場合は、ドライバはカードの全
  ての機能を接続します。ドライバは CIS タプルに相当する機能に接続する事
  だけが可能です。

  戻り値 :

     CS_BAD_SOCKET
        指定したソケット番号は無効です。

  3.2.  ソケット状態管理

  これらの関数は多かれ少なかれ現在のソケットの状態の獲得と設定に関与して
  います。GetStatus は現在のソケット状態を返します。ResetCard はハードリ
  セット信号をソケットに送ります。SuspendCard と ResumeCard は電源オフと
  電源オンを現在接続しているドライバを切り離す事なしに行ないます。
  EjectCard と InsertCard は本質的に実際にカードの排出と挿入イベントを真
  似します。

  3.2.1.  GetStatus

       int CardServices(GetStatus, client_handle_t client, status_t *status);

  status_t データ構造体の定義は次のとおり:

  typedef struct status_t {
          u_char          Function;
          u_long          CardState;
          u_long          SocketState;
  } status_t;

  GetStatus はクライアントのソケットの現在の状態を返します。入出力モード
  に設定されているカードでは、GetStatus はピン代替レジスタと拡張状態レジ
  スタをカード状態を認識するのに使っています。通常のクライアントには
  Function 変数は無視されますが、 BIND_FN_ALL を指定しているクライアント
  ではこの変数で指定した機能の構成レジスタでソケット状態を決定するのに使
  用します。 CardState には次のフラグを定義しています。:

     CS_EVENT_CARD_DETECT
        指定したソケットを使用します。

     CS_EVENT_WRITE_PROTECT
        指定したカードを書き込み禁止にしました。

     CS_EVENT_BATTERY_LOW
        指定したカードの電池が不足しました。

     CS_EVENT_BATTERY_DEAD
        指定したカードは電池切れです。

     CS_EVENT_READY_CHANGE
        指定したカードは準備完了です。

     CS_EVENT_PM_SUSPEND
        指定したソケットは停止しました。

     CS_EVENT_REQUEST_ATTENTION
        指定した拡張状態レジスタ内の要求命令ビットを設定しました。

  SocketState は現在使われていませんが、原則的には CardState の状態変数
  の中に組み込まれていくでしょう。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

  3.2.2.  ResetCard

       int CardServices(ResetCard, client_handle_t client);

  ResetCard はクライアントのソケットのリセットを要求します。この呼び出し
  が発生した時、カードサービスは全てのクライアントに
  CS_EVENT_RESET_REQUEST イベントを送ります。クライアントがこの要求を拒
  否した場合は、カードサービスクライアントを初期化する為に
  CS_EVENT_RESET_COMPLETE イベントを event_callback_args.info にクライア
  ントの要求拒否の返り値を設定してクライアントに送ります。

  全てのクライアントがこの要求に同意すると、カードサービスは
  CS_EVENT_RESET_PHYSICAL イベントを送り、ソケットをリセットします。ソ
  ケット信号が準備完了になると、CS_EVENT_CARD_RESET イベントを生成しま
  す。最後に CS_EVENT_RESET_COMPLETE イベントを event_callback_args.info
  にゼロを設定して初期化するクライアントに送ります。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_IN_USE
        ソケットは現在リセットしています。

  3.2.3.  SuspendCard

       int CardServices(SuspendCard, client_handle_t client);

  カードサービスは全てのクライアントに CS_EVENT_PM_SUSPEND イベントを送
  ります。ソケットをシャットダウンと電源オフさせます。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_IN_USE
        ソケットは既に中止しています。

  3.2.4.  ResumeCard

       int CardServices(ResumeCard, client_handle_t client);

  ソケットが電源オフした後、カードサービスは全てのクライアントに
  CS_EVENT_PM_RESUME イベントを送ります。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_IN_USE
        ソケットは既に中止しています。
  3.2.5.  EjectCard

       int CardServices(EjectCard, client_handle_t client);

  カードサービスは全てのクライアントに 排出 (イジェクト) イベントを送り
  ます。ソケットをシャットダウンと電源オフさせます。全てのクライアントが
  ドライバサービスがソケットを切り離す為にイベントを受け取ります。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

  3.2.6.  InsertCard

       int CardServices(InsertCard, client_handle_t client);

  カードサービスは挿入イベントを全てのソケットのクライアントに送ります。
  (通常、ドライバサービス限定です)

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_IN_USE
        ソケットは既に設定しています。

  3.3.  入出力カードの設定関数

  普通のイベントの順番はドライバ用に入出力ポートと RequestIO と
  RequestIR を呼び出して割り込み線を予約します。そして、
  RequestConfiguration を呼び出して実際のソケットを設定します。これらの
  呼び出しに失敗したら、うまく予約ができるようにリソースを解放するように
  ドライバを確認して下さい。

  多機能カードはそれぞれの機能を分離して設定しましょう。しかしながら他の
  機能と調和している必要があります。それぞれのカード機能はその自身のレジ
  スタのセットを持ち、それぞれのソケットは一つの割り込み線と二つの連続し
  た入出力ポート番号を割り当てます。

  3.3.1.  RequestIO

       int CardServices(RequestIO, client_handle_t client, io_req_t *req);

  io_req_t 構造体の定義は次のとおり:

       typedef struct io_req_t {
               ioaddr_t        BasePort1;
               ioaddr_t        NumPorts1;
               u_long          Attributes1;
               ioaddr_t        BasePort2;
               ioaddr_t        NumPorts2;
               u_long          Attributes2;
               u_long          IOAddrLines;
       } io_req_t;

  RequestIO はカード用入出力領域を予約します。BasePort1 がゼロでない場合
  は、予約する領域の入出力ポートアドレスです。ゼロの場合は、カードサービ
  スが利用できる領域をみつけて、BasePort1 にそのアドレスを設定することで
  す。NumPorts2 がゼロでない場合は、2番目の入出力ポート領域も予約しま
  す。IOAddrLines は PCMCIA カードで実際にデコードするアドレス線の数を指
  定します。これは現在使われていません。

  多機能カードではこの呼び出しでそれぞれの物理ポートに対応する 2 つの低
  層入出力領域を割り付けそれぞれのカード機能に対応した全てのポートに入出
  力ポートを割り当てます。例えば、仮に4機能カードの場合 8 ポートを所有す
  る1つの入出力領域をドライバは割り当て、カードサービスは 1 つの連続した
  32-ポートブロックに統合します。

  この呼び出しは実際のソケットの入出力領域を設定するものではありません。
  続いて RequestConfiguration を呼び出して設定して下さい。

  次のフラグは Attributes1 と Attributes2 に指定します。:

     IO_DATA_PATH_WIDTH
        この変数は 16 ビットアクセス用の IO_DATA_PATH_WIDTH_16 もしくは
        8 ビットアクセス用の IO_DATA_PATH_WIDTH_8 もしくはアクセスするバ
        スの大きさに合わせた動的な領域の大きさを決める
        IO_DATA_PATH_WIDTH_AUTO のどちらか一方に設定します。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_IN_USE
        ソケットの入出力領域は既に予約されています。

     CS_CONFIGURATION_LOCKED
        ソケットの構成は RequestConfiguration によってロックされていま
        す。

     CS_BAD_ATTRIBUTE
        サポートしていない属性フラグが指定されました。
  3.3.2.  ReleaseIO

       int CardServices(ReleaseIO, client_handle_t client, io_req_t *req);

  ReleaseIO は RequestIO が呼ばれる前に割り当てられていた入出力ポート領
  域を解放します。req 変数は RequestIO にそのまま渡します。いくつかのカ
  ードの機能が大きな入出力ポート領域を共有している場合、一つの機能がポー
  トを解放しても全てのカードの機能が入出力ポートを解放するまでは他が使っ
  ているポートを使えなくしてしまってはいけません。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_CONFIGURATION_LOCKED
        ソケットの構成は RequestConfiguration によってロックされていま
        す。その構成は ReleaseIO を呼ぶ前に解放されています。

     CS_BAD_ARGS
        req に入っている変数が RequestIO に渡されたものと一致していませ
        ん。

  3.3.3.  RequestIRQ

       int CardServices(RequestIRQ, client_handle_t client, irq_req_t *req);

  irq_req_t 構造体の定義は次のとおり:

       typedef struct irq_req_t {
               u_long          Attributes;
               u_long          AssignedIRQ;
               u_long          IRQInfo1, IRQInfo2;
               void            *(Handler)(int, struct pt_regs *);
               void            *Instance
       } irq_req_t;

  RequestIRQ は PCMCIA カードが使用する割り込み線を予約します。 IRQInfo1
  と IRQInfo2 変数は CFTABLE_ENTRY タプル内の割り込み記述語と一致してい
  ます。IRQ_INFO2_VALID を IRQInfo1 に設定しているならば IRQInfo2 を割り
  込みの数値を考慮したビットマップマスクを設定しましょう。それぞれのビッ
  トは一つの割り込み線と一致しています。例えばビット 0 は割り込み 0 、
  ビット 1 は割り込み 1 などです。従って、 0x1100 というマスクは割り込み
  12 と割り込み 8 を使う事を意味しています。IRQ_INFO2_VALID を設定してい
  ない場合は、IRQInfo1 は割り込み番号を指定する必要があります。この呼び
  出しが成功した時は、AssignedIRQ に予約された割り込み番号が返ってきま
  す。

  IRQ_HANDLER_PRESENT フラグを設定すると、その時この呼び出しが割り込みが
  有効になっている時に割り込みハンドラを導入することを示していま
  す。RequestConfiguration が呼ばれた時、Handler で指定した割り込みハン
  ドラが導入されます。カーネル 2.0 以降では割り込みハンドラは Instance
  で与えられる ``実体'' のドライバと共に導入されます。カーネル 2.1.60 以
  前では、カーネルの irq2dev_map テーブルも更新するでしょう。多機能カー
  ドでは、割り込みは共有モードで割り当てられ、ハンドラは割り込みを受け
  取った時カードに機能を認識させる役割を負います。クライアントがカードサ
  ービスを迂回する為に独自の割り込みサービスルーチンを導入する場合は、ク
  ライアントが多機能カードと結合するには共有モードで割り当てましょう。

  Attributes で指定できるフラグは次のとおり:

     IRQ_FORCED_PULSE
        指定する割り込みは標準のレベルモードよりはパルスモードで設定しま
        しょう。

     IRQ_TYPE_TIME
        指定する割り込みは他のカードサービスドライバで時分割で行ないま
        しょう。一つのドライバではいつでも割り込み可能になります。

     IRQ_FIRST_SHARED
        IRQ_TYPE_TIME と組み合わせて、最初のドライバを共有割り込みするよ
        うに設定します。

     IRQ_HANDLER_PRESENT
        Handler 変数が導入済みの割り込みサービスルーチンを指すようにしま
        す。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_IN_USE
        ソケットの入出力領域は既に予約されているか、要求した割り込みは使
        用できません。

     CS_CONFIGURATION_LOCKED
        ソケットの構成は RequestConfiguration によってロックされていま
        す。

     CS_BAD_ATTRIBUTE
        サポートしていない属性フラグが指定されました。

  3.3.4.  ReleaseIRQ

       int CardServices(ReleaseIRQ, client_handle_t client, irq_req_t *req);

  ReleaseIRQ はそれ以前に割り当てられている割り込みの予約解除をします。
  req 構造体は RequestIRQ に渡される構造体と同じものです。ハンドラを
  RequestIRQ 呼び出しで指定した場合は、この時点で登録解除されます。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。
     CS_CONFIGURATION_LOCKED
        ソケットの構成は RequestConfiguration によってロックされていま
        す。構成は ReleaseIRQ が呼ばれる前に解除されています。

     CS_BAD_IRQ
        req で指定したパラメータが RequestIRQ に渡されていたものと一致し
        ていません。

  3.3.5.  RequestConfiguration

       int CardServices(RequestConfiguration, client_handle_t client, config_req_t *req);

  config_req_t 構造体の定義は次のとおり:

       typedef struct config_req_t {
               u_long          Attributes;
               u_long          Vcc, Vpp1, Vpp2;
               u_long          IntType;
               caddr_t         ConfigBase;
               u_char          Status, Pin, Copy, ExtStatus;
               u_char          ConfigIndex;
               u_long          Present;
       } config_req_t;

  RequestConfiguration は実際にソケットの構成を行ないます。これは電圧の
  設定、 CIS 構成レジスタの設定、入出力ポート領域の設定、割り込みの設定
  を行ないます。

  IntType は使用するカードのインターフェースの型を指定します。その型は
  INT_MEMORY または INT_MEMORY_AND_IO のいずれかを指定します。 Voltages
  は 1/10 ボルトの単位で指定します。現在は、Vpp1 と Vpp2 は同じである必
  要があります.

  多機能カードではそれぞれのカード機能は別々に構成します。それぞれの機能
  は CIS 構成レジスタの組み合わせで行ないます。しかしながら、全ての機能
  は同じ電源とインタフェースで構成しなければいけません。

  次のフラグは Attributes で指定するものです。DMA とスピーカ制御は全ての
  システムでサポートはしていません。

     CONF_ENABLE_IRQ
        RequestIRQ 以前を入出力割り込みを予約可能にします。

     CONF_ENABLE_DMA
        ソケット用に DMA アクセスを有効にします。

     CONF_ENABLE_SPKR
        ソケットからスピーカ出力を有効にします。

  Present 変数はカードに実装している CIS 構成レジスタで指定するビット
  マップです。ConfigBase は属性メモリ内の構成レジスタのオフセットで与え
  ます。次のレジスタで指定します。:

     PRESENT_OPTION
        現在の構成オプションレジスタ(COR) を指定します。 COR レジスタは
        ConfigIndex 変数を使って指定します。

     PRESENT_STATUS
        現在のカード構成(CC) と 状態レジスタ(SR) を指定します。 CCSR は
        Status 変数で初期化します。

     PRESENT_PIN_REPLACE
        現在のピン代替レジスタ(PRR) を指定します。PRR は Pin 変数で初期
        化します。

     PRESENT_COPY
        現在のソケット(S) とコピーレジスタ(CR) を指定します。SCR は Copy
        変数で初期化します。

     PRESENT_EXT_STATUS
        現在の拡張状態レジスタ(ESR) を指定します。ESR は ExtStatus 変数
        で初期化します。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_OUT_OF_RESOURCE
        カードサービスはカードの構成レジスタにアクセスするメモリ領域が割
        り当てできません。

     CS_CONFIGURATION_LOCKED
        カードの構成は RequestConfiguration によってロックされています。

     CS_BAD_VCC
        要求された Vcc 電圧はサポートしていません。

     CS_BAD_VPP
        要求された Vpp1/Vpp2 電圧はサポートしていません。

  3.3.6.  ModifyConfiguration

       int CardServices(ModifyConfiguration, client_handle_t client, modconf_t *mod);

  modconf_t 構造体の定義は次のとおり:

       typedef struct modconf_t {
               u_long          Attributes;
               u_long          Vcc, Vpp1, Vpp2;
       } modconf_t;

  ModifyConfiguration は RequestConfiguration を呼び出して設定したソケッ
  トの属性を変更します。

  Attributes で指定できるフラグは次のとおり:

     CONF_IRQ_CHANGE_VALID
        CONF_ENABLE_IRQ の設定を変更する事を表しています。

     CONF_ENABLE_IRQ
        ソケットに有効になっている入出力割り込みを指定します。

     CONF_VCC_CHANGE_VALID
        Vcc を変更することを表しています。

     CONF_VPP1_CHANGE_VALID
        Vpp1 を変更することを表しています。

     CONF_VPP2_CHANGE_VALID
        Vpp2 を変更することを表しています。

  現在、Vpp1 と Vpp2 は常に同じ値でなければいけません。従って、2つの値は
  同時に変更する必要があります。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルは無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_CONFIGURATION_LOCKED
        実際には、ソケットはロックされていません。

     CS_BAD_VCC
        要求された Vcc 電圧はサポートしていません。

     CS_BAD_VPP
        要求された Vpp1/Vpp2 電圧はサポートしていません。

  3.3.7.  ReleaseConfiguration

       int CardServices(ReleaseConfiguration, client_handle_t client, config_req_t *req);

  ReleaseConfiguration はそれ以前に設定されている構成の解除をします。
  req 構造体は ソケットを設定するときと同じものです。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効か、ソケットが設定されていません。

  3.3.8.  GetConfigurationInfo

       int CardServices(GetConfigurationInfo, client_handle_t client, config_info_t *config);

  config_info_t 構造体の定義は次のとおり:

       typedef struct config_info_t {
               u_char          Function;
               u_long          Attributes;
               u_long          Vcc, Vpp1, Vpp2;
               u_long          IntType;
               caddr_t         ConfigBase;
               u_char          Status, Pin, Copy, Option, ExtStatus;
               u_long          Present;
               u_long          AssignedIRQ;
               u_long          IRQAttributes;
               ioaddr_t        BasePort1;
               ioaddr_t        NumPorts1;
               u_long          Attributes1;
               ioaddr_t        BasePort2;
               ioaddr_t        NumPorts2;
               u_long          Attributes2;
               u_long          IOAddrLines;
       } config_info_t;

  GetConfigurationInfo は RequestIO, RequestIRQ と RequestConfiguration
  で設定した現在のソケットの構成を返します。完全に構成したソケットに対し
  て適応してください。単機能のカードに結合しているクライアントでは、
  Function 変数は無視され、クライアントが指定している機能のデータを返し
  ます。BIND_FN_ALL と結合しているクライアントではこの変数は指定した関数
  の構成データを返します。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効か、ソケットが設定されていません。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_CONFIGURATION_LOCKED
        実際には、ソケットはロックされていません。

  3.4.  カード情報構造体 (CIS) 使用法

  カード情報構造体 (CIS) は PCMCIA 標準の中で最も分かりにくいところで
  す。全ての第 2 版の PCMCIA カードはここでどう設定するか説明する CIS を
  持っています。CIS はカードの属性メモリ空間の中の``タプル (tuples)''の
  連結リストです。タプルは識別コード、データ長と一連のデータからなりま
  す。いくつかのタプルでのデータの配置はことごとく全てのビットを使うよう
  な明らかな努力を必要とするほど、かなり複雑です。

  ValidateCIS 呼び出しは正当な CIS を使っているカードかどうか調べます。
  GetFirstTuple と GetNextTuple 呼び出しは CIS タプルリストを移動する方
  法です。GetTupleData はタプルからデータを取り出します。そして
  ParseTuple は特に重要な限られた数のタプルを解釈します。

  3.4.1.  GetFirstTuple, GetNextTuple

  #include "cistpl.h"

  int CardServices(GetFirstTuple, client_handle_t client, tuple_t *tuple);
  int CardServices(GetNextTuple, client_handle_t client, tuple_t *tuple);

  tuple_t データ構造体の定義は次のとおり:

       typedef struct tuple_t {
               u_long          Attributes;
               cis_data_t      DesiredTuple;
               u_long          Flags;
               cisdata_t       TupleCode;
               u_long          TupleLink;
               cisdata_t       TupleOffset;
               cisdata_t       TupleDataMax;
               cisdata_t       TupleDataLen;
               cisdata_t       *TupleData;
       } tuple_t;

  GetFirstTuple は DesiredTuple に一致する最初のタプルコードをカードの
  CIS から探します。特別な RETURN_FIRST_TUPLE コードはどんな種類のタプル
  に一致します。TupleCode を最初に一致したタプルのコードに設定しま
  す。TupleLink は属性メモリ内のタプルのアドレスです。

  GetNextTuple は事前に実行した GetFirstTuple が返す tuple_t 構造体を与
  えることを除いて GetFirstTuple に似ています。また、GetNextTuple は次に
  一致させたいタプルを DesiredTuple に返します。

  これらの関数は自動的に CIS 内のリンクタプルを全て手繰って調査します。
  多機能カードでは CISTPL_LONGLINK_MFC タプルを持っているのは、これらの
  関数がクライアントドライバの指している機能を指定した CIS だけを自動的
  に追跡できるようにするためです。クライアントが BIND_FN_ALL を結合して
  いる場合は、全てのタプルが返るでしょう。

  Attributes で指定できるフラグは次のとおり:

     TUPLE_RETURN_LINK
        リンクタプル (CISTPL_LONGLINK_A, CISTPL_LONGLINK_C,
        CISTPL_LONGLINK_MFC, CISTPL_NOLINK, CISTPL_LINKTARGET) を返すこ
        とを表しています。普通はこれらのタプルは暗黙のうちに処理されま
        す。

     TUPLE_RETURN_COMMON
        多機能 CIS の``共有'' CIS セクションのタプルを返すことを表してい
        ます。このフラグがない時は通常、カードサービスはクライアントに結
        合させる機能を表すタプルを返します.

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

     CS_OUT_OF_RESOURCE
        カードサービスはメモリ領域をカードの CIS に割り付けできませんで
        した。

     CS_NO_MORE_ITEMS
        DesiredTuple に一致するタプルはありません。
  3.4.2.  GetTupleData

       #include "cistpl.h"

       int CardServices(GetTupleData, client_handle_t client, tuple_t *tuple);

  GetTupleData は一連のデータを事前に呼んだ GetFirstTuple または
  GetNextTuple の返してきた指定されたタプルから取り出します。
  TupleDataMax の最大長は TupleData バッファにコピーされて、 TupleOffset
  のオフセットから始まります。コピーされたバイト数は TupleDataLen に入っ
  ています。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

     CS_OUT_OF_RESOURCE
        カードサービスはメモリ領域をカードの CIS に割り付けできませんで
        した。

     CS_NO_MORE_ITEMS
        タプルには何もデータが格納されていません。TuppleOffset はタプル
        の長さと等しいかより大きいです。

  3.4.3.  ParseTuple

       #include "cistpl.h"

       int CardServices(ParseTuple, client_handle_t client, tuple_t *tuple, cisparse_t *parse);

  cisparse_t データ 構造体は次のとおり:

       typedef union cisparse_t {
               cistpl_device_t         device;
               cistpl_checksum_t       checksum;
               cistpl_longlink_t       longlink;
               cistpl_longlink_mfc_t   longlink_mfc;
               cistpl_vers_1_t         version_1;
               cistpl_altstr_t         altstr;
               cistpl_jedec_t          jedec;
               cistpl_manfid_t         manfid;
               cistpl_funcid_t         funcid;
               cistpl_config_t         config;
               cistpl_cftable_entry_t  cftable_entry;
               cistpl_device_geo_t     device_geo;
               cistpl_vers_2_t         version_2;
               cistpl_org_t            org;
       } cisparse_t;

  ParseTuple は事前に呼んだ GetTupleData が返してきたタプルのデータを解
  釈します。返ってきた構造体は解析したタプルの型に依存します。これらの構
  造体の定義は cistpl.h ファイルを参照して下さい。そのうちのいくつかは大
  変複雑なものです。

  戻り値 :

     CS_BAD_TUPLE
        タプルの解析中にエラーが発生しました。タプルが不完全か、書式が正
        しくありません。

     CS_UNSUPPORTED_FUNCTION
        ParseTuple が指定されたタプルの型を解析できません。

  3.4.4.  ValidateCIS

       int CardServices(ValidateCIS, client_handle_t client, cisinfo_t *cisinfo);

  cisinfo_t 構造体は次のとおり:

       typedef struct cisinfo_t {
               u_long          Chains;
       } cisinfo_t;

  ValidateCIS はカードが妥当なカード情報構造体(CIS) を持っているか検証し
  ます。Chains に見つかったタプルの数が返ってきます。CIS が解釈不能だと
  思えたら、Chains を 0 に設定します。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

     CS_OUT_OF_RESOURCE
        カードサービスはメモリ領域をカードの CIS に割り付けできませんで
        した。

  3.5.  メモリ領域制御

  それぞれのソケットは4つ以上のメモリ領域を持て、PCMCIA メモリの一部をホ
  ストのアドレス空間に割り付けます。PCMCIA 機器は一般メモリと属性メモリ
  の両方に 16MB 程度アクセスできます。領域は一般に 2 のべき乗の大きさを
  していますが、ホストとカードのアドレス空間では領域の大きさの倍数に境界
  調整しています。

  メモリ領域は RequestWindow を呼び出して初期化します。いくつかの領域属
  性は ModifyWindow を使用して変更を行ないます。領域に割り付けられたカー
  ドメモリの一部は MapMemPage を使用して変更します。領域は ReleaseWindow
  で解放します。他のカードサービス関数とは異なって、client_handle_t ハン
  ドルでなく window_handle_t ハンドルで動作します。

  3.5.1.  RequestWindow

       int CardServices(RequestWindow, client_handle_t *handle, win_req_t *req);

  win_req_t 構造体は次のとおり:

       typedef struct win_req_t {
               u_long          Attributes;
               caddr_t         Base;
               u_long          Size;
               u_long          AccessSpeed;
       } win_req_t;

  RequestWindow はカードメモリの領域をシステムメモリへ割り当てます。呼ぶ
  前に、handle 変数が有効なクライアントハンドルを指すようにします。返っ
  てきたら、この後呼ばれる ModifyWindow、MapMemPage と ReleaseWindow で
  使用する window_handle_t ハンドルで置き換えられます。

  Attributes で指定できるフラグは次のとおり:

     WIN_MEMORY_TYPE
        この変数は一般メモリでは WIN_MEMORY_TYPE_CM 、属性メモリでは
        WIN_MEMORY_TYPE_AM のいずれかになります。

     WIN_DATA_WIDTH
        16 ビットアクセスでは WIN_DATA_WIDTH_16 、8 ビットアクセスなら
        WIN_DATA_WIDTH_8 のいずれかになります。

     WIN_ENABLE
        これを設定すると、領域が使用可能になります。

     WIN_USE_WAIT
        制御装置がカードの MWAIT 信号を監視するように指定します。

  Base はシステムメモリでの領域の基底アドレスを指定します。NULL の場合
  は、カードサービスは最初に見つかった利用可能な領域のアドレスを設定しま
  す。Size は領域の大きさをバイト単位で指定します。AccessSpeed はメモリ
  アクセススピードをナノ秒単位で指定します。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

     CS_NO_CARD
        クライアントに割り付けたソケットは現在使われていません。

     CS_BAD_ATTRIBUTE
        サポートしていない領域の属性が指定されました。

     CS_OUT_OF_RESOURCE
        そのソケットに対するメモリ領域の最大数は使用済みです。

     CS_IN_USE
        RequestWindow はシステムメモリのあき領域が見つけられません。

  3.5.2.  ModifyWindow

       int CardServices(ModifyWindow, window_handle_t, modwin_t *);

  modwin_t 構造体は次のとおり:

       typedef struct modwin_t {
               u_long          Attributes;
               u_long          AccessSpeed;
       } modwin_t;

  ModifyWindow は事前に呼んだ RequestWindow から返ってきた領域ハンドルの
  属性を変更します。変更できる属性は次のとおり:

     WIN_MEMORY_TYPE
        この変数は一般メモリでは WIN_MEMORY_TYPE_CM 、属性メモリでは
        WIN_MEMORY_TYPE_AM のいずれかになります。

     WIN_DATA_WIDTH
        16 ビットアクセスでは WIN_DATA_WIDTH_16 、8 ビットアクセスなら
        WIN_DATA_WIDTH_8 のいずれかになります。

     WIN_ENABLE
        これを設定すると、領域が使用可能になります。

  AccessSpeed はメモリアクセススピードをナノ秒単位で指定します。

  戻り値 :

     CS_BAD_HANDLE
        領域ハンドルは無効です。

  3.5.3.  MapMemPage

       int CardServices(MapMemPage, window_handle_t, memreq_t *);

  memreq_t 構造体は次のとおり:

       typedef struct memreq_t {
               u_long          CardOffset;
               page_t          Page;
       } memreq_t;

  MapMemPage は CardOffset で割り付けたメモリ領域の基底アドレスをカード
  メモリのアドレスに設定します。領域は RequestWindow を呼び出して作成し
  ておきましょう。Page 変数はこの版では実装していませんので、0 に設定し
  てください。

  戻り値 :

     CS_BAD_HANDLE
        領域ハンドルは無効です。

     CS_BAD_PAGE
        Page の値がゼロ以外です。

  3.5.4.  ReleaseWindow

       int CardServices(ReleaseWindow, window_handle_t handle);

  ReleaseWindow は事前に RequestWindow で割り当てたメモリ領域を解放しま
  す。

  戻り値 :

     CS_BAD_HANDLE
        領域ハンドルは無効です。

  3.6.  大容量メモリサービス

  大容量メモリサービスはメモリ領域サービスで提供しているインターフェース
  よりメモリ領域にアクセスするインターフェースはより高度になっています。
  大容量メモリ呼び出しを使用するクライアントは背後にあるメモリの機構やア
  クセス法についての知識は必要ありません。機器に依存したプログラムはメモ
  リテクノロジドライバ(MTD) と呼ばれる特殊なカードサービスに入れていま
  す。

  3.6.1.  RegisterMTD

       int CardServices(RegisterMTD, client_handle_t handle, mtd_reg_t *reg);

  mtd_reg_t データ 構造体は次のとおり:

       typedef union mtd_reg_t {
               u_long          Attributes;
               u_long          Offset;
               u_long          MediaID;
       } mtd_reg_t;

  RegisterMTD はカードサービスにクライアントの MTD が指定したメモリ領域
  を扱う要求を通知します。Offset 変数はメモリ領域の開始アドレスを指定し
  ます。Attributes で指定できる内容は次のとおり:

     REGION_TYPE
        一般メモリでは REGION_TYPE_CM もしくは 属性メモリでは
        REGION_TYPE_AM のどちらかを指定します。

  MediaID 変数はカードサービスが書き込みます。MTD にこのメモリ領域を参照
  する時の要求の一部として渡します。

  一旦、MTD がこの呼び出しでメモリ領域に結合すると、DeregisterClient を
  呼び出すまで結合しつづけます。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

     CS_BAD_OFFSET
        有効なカードのメモリ領域とオフセットが一致しないか、他の MTD が
        既にこのメモリ領域を登録しています。

  3.6.2.  GetFirstRegion, GetNextRegion

       int CardServices(GetFirstRegion, client_handle_t handle, region_info_t *region);
       int CardServices(GetNextRegion, client_handle_t handle, region_info_t *region);

  region_info_t データ 構造体は次のとおり:

       typedef union region_info_t {
               u_long          Attributes;
               u_long          CardOffset;
               u_long          RegionSize;
               u_long          AccessSpeed;
               u_long          BlockSize;
               u_long          PartMultiple;
               u_char          JedecMfr, JedecInfo;
               memory_handle_t next;
       } region_info_t;

  GetFirstRegion と GetNextRegion はカードの CISTPL_DEVICE,
  CISTPL_JEDEC, と CISTPL_DEVICE_GEO タプルの情報を要約しま
  す。CardOffset は領域の開始アドレスを提供します。RegionSize は領域の大
  きさをバイト単位で提供します。 AccessSpeed は機器のサイクル時間をナノ
  秒単位で提供します。 BlockSize は消去ブロックの大きさをバイト単位で提
  供し、PartMultiple は区画の最小の大きさを BlockSize 単位で提供しま
  す。JedecMfr と JedecInfo は 領域が JEDEC に準拠している証明情報を提供
  します。

  Attributes で指定できる変数は次のとおり:

     REGION_TYPE
        一般メモリでは REGION_TYPE_CM もしくは 属性メモリでは
        REGION_TYPE_AM のどちらかを指定します。

  これらの呼び出しが MTD クライアントによって行なわれた時、BindMTD を呼
  び出したクライアントに BindMTD が返すメモリを結合させます。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

     CS_NO_MORE_ITEMS
        メモリ領域が定義されていません。

  3.6.3.  OpenMemory

       int CardServices(OpenMemory, client_handle_t *handle, open_mem_t *req);

  pen_mem_t 構造体は次のとおり:

       typedef struct open_mem_t {
               u_long          Attributes;
               u_long          Offset;
       } open_mem_t;

  OpenMemory は他の大容量メモリサービス経由でメモリ領域をアクセスするハ
  ンドルを獲得します。Offset 変数はアクセスするメモリ領域の基底アドレス
  を指定します。うまくいったら、クライアントハンドル引数は新しいメモリハ
  ンドルに置き換わります。

  Attributes で指定できる変数は次のとおり:

     MEMORY_TYPE
        この引数は一般メモリでは MEMORY_TYPE_CM 、属性メモリでは
        MEMORY_TYPE_AM のいずれかになります。

     MEMORY_EXCLUSIVE
        クライアントがメモリ領域を排他的にアクセスする為に指定します。

  戻り値 :

     CS_BAD_HANDLE
        領域ハンドルが無効です。

     CS_BAD_OFFSET
        有効な領域のオフセットが指定されていないか、大容量メモリ要求と関
        連づける MTD の大容量メモリサービスに領域がありません。

  3.6.4.  CloseMemory

       int CardServices(CloseMemory, memory_handle_t handle);

  CloseMemory は 以前に呼び出した OpenMemory が返したメモリハンドルを解
  放します。クライアントは DeregisterClient を呼び出す前に全てのメモリハ
  ンドルを解放しましょう。

  戻り値 :

     CS_BAD_HANDLE
        メモリハンドルが無効です。

  3.6.5.  ReadMemory, WriteMemory

       int CardServices(ReadMemory, memory_handle_t handle mem_op_t *req, caddr_t buf);
       int CardServices(WriteMemory, memory_handle_t handle, mem_op_t *req, caddr_t buf);

  mem_io_t 構造体は次のとおり:

       typedef struct mem_op_t {
               u_long          Attributes;
               u_long          Offset;
               u_long          Count;
       } mem_op_t;

  ReadMemory と WriteMemory は以前に呼び出した OpenMemory が返した指定し
  たメモリハンドルで指定したカードメモリ領域を読み書きします。 Offset 変
  数はカードメモリ領域の開始アドレスを指定します。 Count 変数は転送する
  バイト数を指定します。buf 変数は ReadMemory 操作用の対象又は
  WriteMemory 操作の対象となるホストメモリのバッファを指します。

  Attributes で指定できる変数は次のとおり:

     MEM_OP_BUFFER
        ホストバッファがユーザメモリセグメントにある時は
        MEM_OP_BUFFER_USER もしくはホストバッファがカーネルメモリにある
        時は MEM_OP_BUFFER_KERNEL を指定します。

     MEM_OP_DISABLE_ERASE
        カード領域を書き込む前に消去しないように指定します。

     MEM_OP_VERIFY
        書き込みの時に検証するときに指定します。

  戻り値 :

     CS_BAD_HANDLE
        領域ハンドルが無効です。

     CS_BAD_OFFSET
        指定したカードオフセットがメモリ領域の終了アドレスを越えていま
        す。

     CS_BAD_SIZE
        指定した転送サイズがメモリ領域の終了アドレスを越えています。

  3.6.6.  RegisterEraseQueue

       int CardServices(RegisterEraseQueue, client_handle_t *handle, eraseq_hdr_t *header);

  eraceq_hdr_t 構造体は次のとおり:

       typedef struct erase_queue_header_t {
               int             QueueEntryCount;
               eraseq_entry_t  *QueueEntryArray;
       } eraseq_hdr_t;

  この呼び出しはカードサービスの消去キューを登録します。 eraseq_handle_t
  ハンドルは *handle に返ります。クライアントが CheckEraseQueue を呼び出
  した時、カードサービスがキューを調べて新しい要求の非同期処理を開始しま
  す。

  eraseq_entry_t 構造体は次のとおり:

       typedef struct eraseq_entry_t {
               memory_handle_t Handle;
               u_char          State;
               u_long          Size;
               u_long          Offset;
               u_long          *Optional;
       } eraseq_entry_t;

  消去キューの登録には、Header 変数は以前に呼ばれた OpenMemory が返した
  メモリハンドルを入れます。State 変数は消去キューの状態を示します。次の
  値が定義されています。:

     ERASE_QUEUED
        新規に要求をした時クライアントが設定します。

     ERASE_IDLE
        登録がアクティブでない時クライアントが設定します。

     ERASE_PASSED
        消去がうまく完了した時 MTD が設定します。

     ERASE_FAILED
        消去に失敗した時 MTD が設定します。

     ERASE_MEDIA_WRPROT
        領域が書き込み禁止になっている事を示しています。

     ERASE_NOT_ERASABLE
        領域が消去をサポートしていない事を示しています。

     ERASE_BAD_OFFSET
        消去が消去ブロックの境界で始まっていない事を示しています。

     ERASE_BAD_SIZE
        要求している消去の大きさが消去ブロックの倍数になっていない事を示
        しています。

     ERASE_BAD_SOCKET
        MTD がカードがない事を示しています。

  加えて、ERASE_IN_PROGRESS() マクロは処理している消去の State の値の真
  の状態を返します。

  Size 変数は消去要求を大きさをバイト単位で与えます。Offset 変数は領域の
  開始位置からのオフセットで与えます。大きさとオフセットは消去ブロック境
  界に境界調整しておきます。Optional 変数はカードサービスでは使われてい
  ませんが、クライアントドライバで使われています。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが無効です。

  3.6.7.  DeregisterEraseQueue

       int CardServices(DeregisterEraseQueue, eraseq_handle_t handle);

  DeregisterEraseQueue は以前に RegisterEraseQueue により登録されたキュ
  ーを解放します。指定されたキューに処理中のキューがある場合は、呼び出し
  は失敗します。

  戻り値 :

     CS_BAD_HANDLE
        消去キューハンドルが無効です。

     CS_BUSY
        消去キューが消去処理中です。

  3.6.8.  CheckEraseQueue

       int CardServices(CheckEraseQueue, eraseq_handle_t handle);

  この呼び出しは以前に RegisterEraseQueue で登録された新しい消去要求をカ
  ードサービスに通知します。

  例によって、クライアントは最初にそれぞれのキューに ERASE_IDLE 状態を割
  り当てます。キューに新しい要求が追加された時は、クライアントはキューの
  状態を ERASE_QUEUED にして、CheckEraseQueue を呼びます。クライアントが
  消去完了イベントを受け取った場合は、要求が成功したか状態変数を確認しま
  す。

  戻り値 :

     CS_BAD_HANDLE
        消去キューハンドルが無効です。

  3.7.  各種呼び出し

  3.7.1.  GetCardServicesInfo

       int CardServices(GetCardServicesInfo, servinfo_t *info);

  servinfo_t 構造体は次のとおり:

       typedef struct servinfo_t {
               char            Signature[2];
               u_long          Count;
               u_long          Revision;
               u_long          CSLevel;
               char            *VendorString;
       } servinfo_t;

  GetCardServicesInfo はこのカードサービスのバージョンの修正情報を返しま
  す。Signature は ``CS'' に設定します。Count は現状構成のソケットの数を
  設定します。 Revision にはカードサービスパッケージの修正レベルを設定し
  CSLevel は PCMCIA 標準に準じたレベルを設定します。BCD 数で表記していま
  す。VendorString は RCS 識別文字列へのポインタを設定します。

  この呼び出しは常に成功します。

  3.7.2.  AccessConfigurationRegister

       #include "cisreg.h"

       int CardServices(AccessConfigurationRegister, client_handle_t handle, conf_reg_t *reg);

       resource.memory で記述したメモリの範囲を指定します。

     RES_IO_RANGE
        adj->resource.io で記述した入出力ポートを指定します。

     RES_IRQ
        adj->resource.irq で記述した割り込みを指定します。

  Attributes で指定できる内容は次のとおり:

     RES_RESERVED
        PCMCIA ドライバ用に要求し,予約した資源を示しています。利用可能
        なカードサービスの問い合わせしたデバイス用の資源ではありません。
        これは未だ実装していません。

  戻り値 :

     CS_UNSUPPORTED_FUNCTION
        指定した Action と Resource はサポートしていません。

     CS_BAD_BASE
        指定した入出力アドレスは範囲外です。
     CS_BAD_SIZE
        指定したメモリまたは入出力領域のサイズは範囲外です。

     CS_IN_USE
        指定した割り込みは現在カードサービスクライアントが使用中です。

  3.7.4.  ReportError

       int CardServices(ReportError, client_handle_t handle, error_info_t *err);

  error_info_T 構造体の定義は次のとおり:

       typedef struct error_info_t {
              int             func;
              int             retcode;
       } error_info_t;

  ReportError は指定した prefix 文字列とカードサービスの機能コードと戻り
  値を含んだカーネルエラーメッセージを生成します。例を挙げると :

       error_info_t err = { RequestIO, CS_BAD_HANDLE };
       CardServices(ReportError, handle, &err);

  は次のメッセージを生成します。:

       serial_cs: RequestIO: Bad handle

  この呼び出しは常に正常終了します。

  4.  カード情報構造体 (CIS) の定義

  4.1.  CIS タプルの定義

  カードサービスタプル解析 (Card Services ParseTuple) 機能は、
  GetTupleData で得た生の CIS タプルを解析し、それぞれのタプルの種類に依
  存した形式でタプルの内容を返します。

  #include "cistpl.h"

  4.1.1.  CISTPL_CHECKSUM

  cistpl_checksum_t 構造体の定義は次のとおり:

       typedef struct cistpl_checksum_t {
               u_short         addr;
               u_short         len;
               u_char          sum;
       } cistpl_checksum_t;

  4.1.2.  CISTPL_LONGLINK_A, CISTPL_LONGLINK_C, CISTPL_LINKTARGET,
  CISTPL_NOLINK

  cistpl_longlink_t 構造体の定義は次のとおり:

       typedef struct cistpl_longlink_t {
               u_long          addr;
       } cistpl_longlink_t;

  これらのタプルは属性や、一般メモリなどへの他の CIS タプルチェーンへの
  ポインタになっています。それぞれの CIS タプルは、少なくとも 1 以上の長
  さのリンクです。CISTPL_LONGLINK_A タプルは、アトリビュートメモリへのポ
  インタであり、CISTPL_LONGLINK_C タプルは一般メモリへのポインタです。属
  性メモリのアドレス 0 から始まる標準 CIS チェーンは、同時に一般メモリの
  アドレス 0 へのリンクも意味しています。(@@) このようなデフォールトのリ
  ンクをキャンセルしたい場合には CISTPL_NOLINK というタプルを使います。

  ロングリンクによって指されるチェーンの最初のタプル
  は、CISTPL_LINKTARGET でなければなりません。CS タプルを扱うコードは自
  動的にロングリンクをたどり、リンク先を(ターゲット)を調べま
  す。GetNextTuple によって、 TUPLE_RETURN_LINK 属性が指定されていない限
  り、これらのタプルはユーザーからは見えません。

  4.1.3.  CISTPL_LONGLINK_MFC

  cistpl_longlink_mfc_t 構造体の定義は次のとおり:

  typedef struct cistpl_longlink_mfc_t {
          int     nfn;
          struct {
                  u_char  space;
                  u_long  addr;
          } fn[CISTPL_MAX_FUNCTIONS;
  } cistpl_longlink_mfc_t;

  このタプルはマルチファンクション(多機能)カードを識別するのに使われま
  す。それぞれの機能ごとの CIS チェーンへのロングリンクポインタを指定し
  ます。 space 変数は、属性の場合 CISTPL_MFC_ATTR が、一般メモリの場合に
  は CISTPL_MFC_COMMON が指定されます。

  4.1.4.  CISTPL_DEVICE, CISTPL_DEVICE_A

  cistpl_device_t 構造体の定義は次のとおり:

       typedef struct cistpl_device_t {
               int             ndev;
               struct device_info {
                       u_char          type;
                       u_char          wp;
                       u_long          speed;
                       u_long          size;
               } dev[CISTPL_MAX_DEVICES];
       } cistpl_device_t;

  CISTPL_DEVICE タプルはカードの一般メモリのアドレス領域に関して記述して
  います。CISTPL_DEVICE_A タプルは属性メモリ領域を記述しています。 type
  フラグはその領域に関するメモリデバイスの種類を示します。 wp フラグは、
  その領域がライトプロテクトされているかどうかを示します。 speed 変数は
  ナノ秒単位で、size はバイト単位で示されます。アドレス領域はアドレス 0
  番地から連続した領域であることが仮定されています。次のようなデバイスタ
  イプが定義されています。

     CISTPL_DTYPE_NULL
        なにもデバイスが存在しない、または、そのカードのアドレス空間の中
        で「穴」であることを示します。

     CISTPL_DTYPE_ROM
        マスク ROM です。

     CISTPL_DTYPE_OTPROM
        一度だけ書き込み可能な ROM です。(訳注:原文の 「One-type」は
        「One-time」の間違いであると思います。)

     CISTPL_DTYPE_EPROM
        紫外線消去可能な PROM です。(UV-EPROM)

     CISTPL_DTYPE_EEPROM
        電気的に消去可能な PROM です。

     CISTPL_DTYPE_FLASH
        フラッシュ EPROM です。

     CISTPL_DTYPE_SRAM
        スタティックまたは不揮発性の RAM です。

     CISTPL_DTYPE_DRAM
        ダイナミックまたは揮発性の RAM です。

     CISTPL_DTYPE_FUNCSPEC
        機能定義可能なデバイスであることを示します。つまり、汎用の記憶で
        はなくて、例えば メモリーマップドI/O デバイスやバッファのような
        ものです。

     CISTPL_DTYPE_EXTEND
        拡張型のデバイスタイプを示します。これは将来の拡張のために予約さ
        れています。

  4.1.5.  CISTPL_VERS_1

  cistpl_vers_1_t 構造体の定義は次のとおり:

       typedef struct cistpl_vers_1_t {
               u_char          major;
               u_char          minor;
               int             ns;
               int             ofs[CISTPL_VERS_1_MAX_PROD_STRINGS];
               char            str[254];
       } cistpl_vers_1_t;

  ns 変数は、このタプルの中に含まれている製品情報文字列の長さを示してい
  ます。文字列情報は str という配列に格納されています。それぞれの文字列
  はヌル文字で終っており、ofs はそれぞれの文字列の始まりへのオフセットを
  示しています。

  4.1.6.  CISTPL_ALTSTR

  cistpl_altstr_t 構造体の定義は次のとおり:

       typedef struct cistpl_altstr_t {
               int             ns;
               int             ofs[CISTPL_ALTSTR_MAX_STRINGS];
               char            str[254];
       } cistpl_altstr_t;

  ns 変数は、このタプルに含まれている代替用語文字列の数を示しています。
  実際の文字列は、str 配列に格納されています。それぞれの文字列はヌル文字
  で終っており、ofs はそれぞれの文字列の始まりへのオフセットを示していま
  す。

  4.1.7.  CISTPL_JEDEC_C, CISTPL_JEDEC_A

  cistpl_jedec_t 構造体の定義は次のとおり:

       typedef struct cistpl_jedec_t {
               int             nid;
               struct jedec_id {
                       u_char  mfr;
                       u_char  info;
               } id[CISTPL_MAX_DEVICES];
       } cistpl_jedec_t;

  jedec_id (JEDEC 識別子) は、PCMCIA メモリを実現するために使われる特定
  のデバイスタイプを記述しています。 nid 変数はこのタプルの中にいくつの
  jedec_id が含まれているかを示します。このjedec_id (JEDEC identifier)
  と、それに対応する CISTPL_DEVICE タプルの中のデバイス定義は、一対一の
  対応がとれていなければなりません。

  4.1.8.  CISTPL_CONFIG

  cistpl_config_t 構造体の定義は次のとおり:

       typedef struct cistpl_config_t {
               u_char          last_idx;
               u_long          base;
               u_long          rmask[4];
               u_char          subtuples;
       } cistpl_config_t;

  last_idx 変数は、構成情報テーブルの一番最後の項目のインデックスを示し
  ます。 base 変数は、属性メモリ中にあるカードの構成情報レジスタへのオフ
  セットを示します。 rmask 配列はどの構成情報レジスタが存在するのかを示
  すビットマスクです。 rmask[0] のビット 0 は、COR に対応し、ビット 1 は
  CCSR に対応する...  といった具合です。subtuple 変数は、通常のタプルの
  内容に続いて何バイトのタプルが存在するか、を示しています。

  4.1.9.  CISTPL_CFTABLE_ENTRY

  cistpl_cftable_entry_t 構造体の定義は次のとおり:

  typedef struct cistpl_cftable_entry_t {
          u_char          index;
          u_char          flags;
          u_char          interface;
          cistpl_power_t  vcc, vpp1, vpp2;
          cistpl_timing_t timing;
          cistpl_io_t     io;
          cistpl_irq_t    irq;
          cistpl_mem_t    mem;
          u_char          subtuples;
  } cistpl_cftable_entry_t;

  CISTPL_CFTABLE_ENTRY 構造体はそのカードに対する完全な動作モードを記述
  しています。多くの部分が省略可能です。index 変数はこの動作モードについ
  ての構成情報インデックスを示します。カードの Configuration Option
  Register にこの値を書き込むことでこのモードを選択することができま
  す。flags 変数には、次の値が定義されています:

     CISTPL_CFTABLE_DEFAULT
        デフォールトの構成情報テーブルの項目であることを示します。

     CISTPL_CFTABLE_BVDS
        この設定は ピン代替レジスタ 中で BVD1 と BVD2 信号を実装している
        ことを示します。

     CISTPL_CFTABLE_WP
        この設定は ピン代替レジスタ 中で 書き込み禁止を実装していること
        を示します。

     CISTPL_CFTABLE_RDYBSY
        この設定は ピン代替レジスタ 中で Ready/Busy 信号を実装しているこ
        とを示します。

     CISTPL_CFTABLE_MWAIT
        メモリーアクセス中に、WAIT 信号を使う必要があることを示します。

     CISTPL_CFTABLE_AUDIO
        この設定はオーディオ信号を発生し、ホストシステムのスピーカーに出
        力することができることを示します。

     CISTPL_CFTABLE_READONLY
        この設定ではカード中に読みだし専用のメモリ領域が存在することを示
        します。

     CISTPL_CFTABLE_PWRDOWN
        カード構成情報と状態レジスタ を通じて、パワーダウンモードをサポ
        ートしていることを示します。

  cistpl_power_t 構造体の定義は次のとおり:

       typedef struct cistpl_power_t {
               u_char          present;
               u_char          flags;
               u_long          param[7];
       } cistpl_power_t;

  present 変数はビットマップ形式になっており、この電源信号に関して、どの
  パラメータが存在しているか、を示します。次のようなインデックスが定義さ
  れています:

     CISTPL_POWER_VNOM
        標準的な電源電圧

     CISTPL_POWER_VMIN
        最低電源電圧

     CISTPL_POWER_VMAX
        最高電源電圧

     CISTPL_POWER_ISTATIC
        連続供給が必要な電源電流

     CISTPL_POWER_IAVG
        1 秒間を通じて平均した最大供給電流

     CISTPL_POWER_IPEAK
        10m 秒間を通じて平均した最大供給電流

     CISTPL_POWER_IDOWN
        パワーダウンモードで必要な供給電流

  電圧は 10 マイクロボルト単位、電流は 100 ナノアンペア単位で表されてい
  ます。

  cistpl_timing_t 構造体の定義は次のとおり:

       typedef cistpl_timing_t {
               u_long          wait, waitscale;
               u_long          ready, rdyscale;
               u_long          reserved, rsvscale;
       } cistpl_timing_t;

  それぞれの時間はナノ秒を基底とした値と、尺度乗数から構成されています。
  定義されていない(Unspecified) 時間の値は 0 です。

  cistpl_io_t 構造体の定義は次のとおり:

       typedef struct cistpl_io_t {
               u_char          flags;
               int             nwin;
               struct {
                       u_long          base;
                       u_long          len;
               } win[CISTPL_IO_MAX_WIN;
       } cistpl_io_t;

  nwin は 入出力領域の数を示します。それぞれの領域は基底アドレス: base、
  バイト単位での長さ: len で記述されます。 flags では、次のようなビット
  マップが定義されています:

     CISTPL_IO_LINES_MASK
        このカードでデコードされる入出力の本数。

     CISTPL_IO_8BIT
        このカードは 16 ビットの入出力レジスタに対して、独立した 8 ビッ
        トアクセスをサポートしていることを示す。

     CISTPL_IO_16BIT
        このカードは入出力レジスタに対して 16 ビットアクセスをサポートし
        ていることを示す。

  cistpl_irq_t 構造体の定義は次のとおり:

       typedef struct cistpl_irq_t {
               u_long          IRQInfo1;
               u_long          IRQInfo2;
       } cistpl_irq_t;

  IRQInfo1 では次のビットマップが定義されています:

     IRQ_MASK
        このカードが使うべき割り込み番号を示す。

     IRQ_NMI_ID, IRQ_IOCK_ID, IRQ_BERR_ID,
        IRQ_VEND_ID" IRQ_INFO2_VALID がセットされている時、これらのビッ
        トマップはそれぞれの特殊割り込みがこのカードに割り当てられている
        かどうかを示す。これら4つのフラグはそれぞれ、マスク不可能、 IO
        チェック、バスエラー、ベンダー特有の割り込みを意味します。

     IRQ_INFO2_VALID
        IRQInfo2 が、許可された、正しい割り込み番号を含んでいることを示
        す。

     IRQ_LEVEL_ID
        このカードはレベル割り込みをサポートしていることを示す。

     IRQ_PULSE_ID
        このカードはパルス割り込みをサポートしていることを示す。

     IRQ_SHARE_ID
        このカードは割り込み共有をサポートしていることを示す。

  IRQInfo1 が 0 の場合、割り込みに関する情報は存在しないことを意味しま
  す。

  cistpl_mem_t 構造体の定義は次のとおり:

       typedef struct cistpl_mem_t {
               u_char          nwin;
               struct {
                       u_long          len;
                       u_long          card_addr;
                       caddr_t         host_addr;
               } win[CISTPL_MEM_MAX_WIN;
       } cistpl_mem_t;

  nwin はメモリ領域の数を示す。それぞれの領域は、カードのメモリ空間中の
  アドレス: card_addr、ホストのメモリ空間中のアドレス: host_addr、バイト
  単位での長さ: len で定義される。ホストアドレスが 0 の場合、領域の位置
  は任意 (arbitrary) であることを意味する。

  4.1.10.  CISTPL_MANFID

  cistpl_manfid_t 構造体の定義は次のとおり:

       typedef struct cistpl_manfid_t {
               u_short         manf;
               u_short         card;
       } cistpl_manfid_t;

  manf 変数はそのカードの製造業者を表します。 card 変数はそれぞれのベン
  ダーによって定義され、カードの種類と、モデルを識別できるようにしなけれ
  ばなりません。

  4.1.11.  CISTPL_FUNCID

  cistpl_funcid_t 構造体の定義は次のとおり:

       typedef struct cistpl_funcid_t {
               u_char          func;
               u_char          sysinit;
       } cistpl_funcid_t;

  func 変数はそのカードの機能を表します。sysinit 変数はブート時にそのカ
  ードがどのように設定されるべきかをビットマップフラグで示してます。

  次の機能が定義されています:

     CISTPL_FUNCID_MULTI
        マルチファンクション(多機能)カード

     CISTPL_FUNCID_MEMORY
        単純なメモリデバイス

     CISTPL_FUNCID_SERIAL
        シリアルポートまたはモデムデバイス

     CISTPL_FUNCID_PARALLEL
        パラレルポートデバイス

     CISTPL_FUNCID_FIXED
        固定ディスクデバイス(ハードディスクなど)

     CISTPL_FUNCID_VIDEO
        ビデオインターフェース

     CISTPL_FUNCID_NETWORK
        ネットワークアダプタ

     CISTPL_FUNCID_AIMS
        自動増分機能のある大容量記憶装置

  sysinit では次のフラグが定義されている:

     CISTPL_SYSINIT_POST
        システムのパワーオン初期化時にこのカードの設定を試みる必要がある
        ことを示す。

     CISTPL_SYSINIT_ROM
        このカードは、ブート時に設定する必要のあるシステム拡張 ROM を含
        んでいることを示す。

  4.1.12.  CISTPL_DEVICE_GEO

  cistpl_device_geo_t 構造体の定義は次のとおり:

       typedef struct cistpl_device_geo_t {
               int             ngeo;
               struct geo {
                       u_char          buswidth;
                       u_long          erase_block;
                       u_long          read_block;
                       u_long          write_block;
                       u_long          partition;
                       u_long          interleave;
               } geo[CISTPL_MAX_DEVICES];
       } cistpl_device_geo_t;

  erase_block, read_block, write_block の大きさは、それぞれ buswidth の
  値に interleave の値を乗じたバイト数を単位として表される。 partition
  の大きさは、erase_block の大きさを単位として表される。

  4.1.13.  CISTPL_VERS_2

  cistpl_vers_2_t 構造体の定義は次のとおり:

       typedef struct cistpl_vers_2_t {
               u_char          vers;
               u_char          comply;
               u_short         dindex;
               u_char          vspec8, vspec9;
               u_char          nhdr;
               int             vendor, info;
               char            str[244];
       } cistpl_vers_2_t;

  vers 変数は常に 0 でなければなりません。comply 変数は標準への準拠の度
  合を示しますが、同じく 0 でなければなりません。 dindex 変数は一般メモ
  リの最初の何バイトが予約されているかを示します。vspec8 と vspec9 変数
  にはベンダー特有の情報が含まれている場合があります。nhdr 変数はこのカ
  ード上にいくつの CIS のコピーが存在しているかを示します。 str 配列は、
  二つの文字列を含んでいます: ベンダーの名前と、このカードについて記述し
  ているなんらかの情報です。ベンダー名の文字列へのオフセットは vendor で
  示され、製品情報の文字列へのオフセットは info で示されます。

  4.1.14.  CISTPL_ORG

  cistpl_org_t 構造体の定義は次のとおり:

       typedef struct cistpl_org_t {
               u_char          data_org;
               char            desc[30];

  このタプルはメモリパーティッションのデータの構成を定義します。
  data_org には次の値が定義されています:

     CISTPL_ORG_FS
        このパーティッションはファイルシステムを含んでいます。

     CISTPL_ORG_APPSPEC
        このパーティッションはアプリケーション特有の形式です。

     CISTPL_ORG_XIP
        このパーティッションは「その場で実行」(Execute-In-Place)仕様に従
        います。

  desc 変数には、データの構成についての文字による記述が含まれています。

  4.2.  CIS 構成レジスタ

  PCMCIA 標準規格は、カードの属性メモリ空間中に、いくつかの標準的な構成
  情報レジスタを定義しています。これらのレジスタのうち、どのレジスタが実
  装されているかは、カードの CONFIG タプルに記述されています。これらの定
  義を使う必要のあるプログラムは次をインクルードする必要があります:

       #include "cisreg.h"

  4.2.1.  Configuration Option Register

  このレジスタに書き込むことによって、構成情報テーブルの項目を選択し、カ
  ードの入出力機能が使えるようになります。

  次のビット変数が定義されています:

     COR_CONFIG_MASK
        構成情報テーブルインデックスは、カードの現在の動作モードを指して
        いることを示す。

     COR_LEVEL_REQ
        このカードはレベル(エッジトリガー)割り込みを生成することを示しま
        す。これはデフォールトです。

     COR_SOFT_RESET
        このビットをセットすることで、「ソフト」リセット動作を実行しま
        す。カードをリセットしたい時には、ドライバはこのレジスタに直接に
        書き込むのではなく、ResetCard 呼び出しを使うべきです。

  4.2.2.  カードの構成情報と状態レジスタ

  次のビット変数が定義されています:

     CCSR_INTR_ACK
        このビットが設定されている場合、CCSR_INTR_PENDING ビットは陽にク
        リアされるまでセットされたままになります。

     CCSR_INTR_PENDING
        このカードが現在割り込み要求をしていることを示す。この信号は割り
        込み共有を目的として使われることもあります。

     CCSR_POWER_DOWN
        このビットをセットすると、カードに対してパワーダウンモードに入る
        ことを要求します。

     CCSR_AUDIO_ENA
        このビットをセットすると、カードのオーディオ出力を可能にします。

     CCSR_IOIS8
        このビットをセットすることで、このホストは 8 ビット入出力しか行
        なえないので、16 ビットの入出力は二回に分けた 8 ビット入出力で実
        行することを通知します。

     CCSR_SIGCHG_ENA
        このビットをセットすることで、カードが WP, READY, BVD1, BVD2 信
        号の変化を、SIGCHG 信号を通じて伝えるように要求します。

     CCSR_CHANGED
        このビットがセットされることで、ピン代替レジスタのいずれかのビッ
        トの状態が変化したことがホストに通知されます。

  4.2.3.  ピン代替レジスタ

  ソケットがメモリ/入出力モードで動作する時に使えなくなってしまう(ピン
  の) 信号をこのレジスタの中の信号で置き換えることができます。 (訳注: ピ
  ンが足りなくなってしまって、ソケット経由で引き出すことができなくなった
  信号をソフトウエア的にこのレジスタを通じて読み出すことができるという意
  味でしょう) このレジスタの中の信号のどれかが変化した時には通常、カード
  は SIGCHG 信号をアサートし、ドライバはこのレジスタを読み出すことで、何
  が起きたのかを知ることができます。

  次のビット変数が定義されています:

     PRR_WP_STATUS
        書き込み信号の現在の状態。

     PRR_READY_STATUS
        レディ信号の現在の状態。

     PRR_BVD2_STATUS
        電池警告信号の現在の状態。

     PRR_BVD1_STATUS
        電池切れ信号の現在の状態。

     PRR_WP_EVENT
        最後に PRR レジスタが読み出されてから、書き込み禁止信号が変化し
        たことを示す。

     PRR_READY_EVENT
        最後に PRR レジスタが読み出されてから、レディ信号が変化したこと
        を示す。

     PRR_BVD2_EVENT
        最後に PRR レジスタが読み出されてから、電池警告信号が変化したこ
        とを示す。

     PRR_BVD1_EVENT
        最後に PRR レジスタが読み出されてから、電池切れ信号が変化したこ
        とを示す。

  このレジスタは書き込みも可能です。この場合には STATUS ビットはマスクと
  して機能します。つまり、その STATUS ビットがセットされている場合には、
  対応するEVENT のビットが書き込みによって更新されます。

  4.2.4.  ソケットとコピーレジスタ

  このレジスタは、いくつかの同じカードが同じ範囲の入出力ポートを共有する
  ような設定を可能にするような場合や、いくつかのデバイスを制御する ISA
  バスのカードをエミュレートする場合に使われます。例えば、一枚の ISA ハ
  ードディスクコントローラは、入出力ポートにドライブ番号を書き込むことで
  複数のドライブを制御することができます。何枚かの PCMCIA ドライブカード
  によってこのようなコントローラをエミュレートするためには、どの入出力操
  作がどれに対するものであるかを識別できるように、それぞれのカードが自分
  がどのドライブであるかを「知る」必要があります。

  次のビット変数が定義されています:

     SCR_SOCKET_NUM
        カードの位置するソケット番号を表している必要があります。

     SCR_COPY_NUM
        複数の同じカードがシステムに存在する時には、この変数はそれらのカ
        ードのどれであるのかを識別するための特有な番号に設定されている必
        要があります。

  4.2.5.  拡張状態レジスタ

  次のビット変数が定義されています:

     ESR_REQ_ATTN_ENA
        セットされると、ESR_REQ_ATTN ビットがセットされた時に
        CCSR_CHANGED ビットもセットされるのと同様にどうしても状態変化割
        り込みが発生します。

     ESR_REQ_ATTN
        モデムへ着信があったときなど、なんらかのカードイベントが発生した
        ことを示します。

  5.  カードサービスイベントの扱いについて

  カードサービスイベントはいくつかの情報源を持っています。:

  o  カードの状態変更が下位のソケットドライバから報告されました。

  o  カードサービス自身が人為的なイベントを発生させました。

  o  アドバンスドパワーマネージメント(APM) のイベント。

  o  その他のカードサービスクライアントが発生させたイベント。

  ソケットドライバのイベントは割り込み駆動またはポーリングのどちらかとな
  ります。

  5.1.  イベントハンドラの操作

  カードサービスがイベントが発生した事を認識した時に、それぞれのクライア
  ントがイベント通知を受けたかイベントマスクを調査します。カードサービス
  にクライアントか登録された時、イベントハンドラの回収(callback)関数を指
  定します。このハンドラは次の様式をしています。:

       int (*event_handler)(event_t event, int priority, event_callback_args_t *args);

  priority 変数は通常のイベント用の CS_EVENT_PRI_LOW か即時応答要求のイ
  ベント用の CS_EVENT_PRI_HIGH なのかを設定します。高優先順位のイベント
  のみ CS_EVENT_CARD_REMOVAL を設定します。クライアントイベントハンドラ
  はこの高優先順位のイベントを特に出来るだけ速くカードサービスが他のクラ
  イアントに通知出来るように処理します。

  event_callback_args_t 構造体の定義は次のとおり:

       typedef struct event_callback_args_t {
               client_handle_t         client_handle;
               void                    *info;
               void                    *mtdrequest;
               void                    *buffer;
               void                    *misc;
               void                    *client_data;
       } event_callback_args_t;

  client_handle メンバはイベントに対応するソケットのクライアントのハンド
  ラを設定します。この方法はドライバがいくつかのソケットと結合している場
  合に有益です。info 変数は現状では ResetCard へ渡す呼出しの終了状態を返
  すのに使われるだけです。client_data 変数は該当するデバイスと関連するロ
  ーカルなデータ構造体を指すのにドライバが使います。他の変数は使われてい
  ません。

  5.2.  イベントの説明

     CS_EVENT_CARD_INSERTION
        カードが挿入された事を表すイベント信号。ドライバが使用中のソケッ
        トに結合されている場合は、カードサービスはドライバに人為的に挿入
        イベントを送出します。

     CS_EVENT_CARD_REMOVAL
        カードが抜かれた事を表すイベント信号。このイベントはカードサービ
        スが全てのクライアントに可能な限り速く通知する為に最小の遅延時間
        で取り扱います。

     CS_EVENT_BATTERY_LOW
        ``電池不足''状態に変化した事を表すイベント信号。

     CS_EVENT_BATTERY_DEAD
        ``電池切れ''状態に変化した事を表すイベント信号。

     CS_EVENT_READY_CHANGE
        ``準備完了''状態に変化した事を表すイベント信号。

     CS_EVENT_WRITE_PROTECT
        ``書き込み禁止''状態に変化した事を表すイベント信号。

     CS_EVENT_REGISTRATION_COMPLETE
        RegisterClient の呼び出しが成功した後にドライバに送るイベント。

     CS_EVENT_RESET_REQUEST
        クライアントが ResetCard を呼んだ時に送るイベント。イベントハン
        ドラは呼び出しが失敗したらリセット操作を拒否できます。

     CS_EVENT_RESET_PHYSICAL
        リセット信号をカードに送る直前に全てのクライアントに送ります。

     CS_EVENT_CARD_RESET
        リセット操作が終了したら送るイベント信号。リセットが成功したか失
        敗したかは GetStatus を使用して認識します。

     CS_EVENT_RESET_COMPLETE
        ResetCard を呼んでリセット処理の完了したことをクライアントに通知
        するイベント。

     CS_EVENT_PM_SUSPEND
        カードサービスがユーザの初期化または APM サスペンド要求を受け
        取った事を表すイベント信号。イベントハンドラは呼び出しが失敗した
        らサスペンドを拒否できます。

     CS_EVENT_PM_RESUME
        サスペンド/リジューム命令の後でシステムが停止したことを表す信
        号。

     CS_EVENT_MTD_REQUEST
        MTD メモリ操作の初期化に使います。要求の種類は callback 引数の
        mtdrequest 変数の中に渡されます。ホストのバッファアドレスは
        buffer 変数に渡されます。

     CS_EVENT_ERASE_COMPLETE
        キューに入れた消去操作が終了した事をクライアントに通知するのに使
        用します。消去キューへのポインタは callback 引数の info 変数に返
        ります。

  5.3.  クライアントドライバのイベント操作の役割について

  クライアントドライバはソケットが設定されたか解除されたかによって発生す
  る CS_EVENT_CARD_INSERTION イベントと CS_EVENT_CARD_REMOVAL イベントに
  応答します。従ってカードの除去は高い優先度のイベントなのでドライバは即
  時にソケットとの入出力を遮断し、device 構造体にフラグを設定し、その他
  全ての処理を後で発生する時間割り込みを使用して中止するように予定に組み
  込みます。

  CS_EVENT_PM_RESET_REQUEST イベントを受け取った時は、ドライバは入出力を
  遮断しロックしたソケットの設定を解放し、ドライバはソケットの設定と遮断
  前の入出力を格納します。CS_EVENT_CARD_RESET を受け取った時は、ドライバ
  構成を格納し入出力の封鎖を解きます。

  入出力が遮断されかつソケットの構成が解放された場合に
  CS_EVENT_PM_SUSPEND イベントは大体 CS_EVENT_PM_RESET_REQUEST イベント
  のように扱われます。 CS_EVENT_PM_RESUME イベントを受け取った時はドライ
  バがカードの再設定の準備が出来ている場合を除いて、CS_EVENT_CARD_RESET
  イベントを受け取った時と同様です。

  6.  メモリテクノロジドライバ

  メモリテクノロジドライバ (``MTD'') は、ある種のメモリデバイスでさまざ
  まなメモリサービスを実現するために、カードサービスが使用します。 MTD
  は、RegisterClient を呼び出して、通常のカードサービスのクライアントと
  して登録しなければなりません。カード挿入のイベントを受け取ったら、管理
  するメモリの範囲を知るために、GetFirstRegion と GetNextRegion を呼び出
  します。そうしたら、RegisterMTD を使ってそれらの範囲を制御します。MTD
  の読み出し、書き込み、消去の要求は、カードサービスによって
  CS_EVENT_MTD_REQUEST にパッケージ化され、MTD のイベントハンドラに渡さ
  れて処理されます。

  6.1.  MTD 要求の処理

  MTD は、カードサービスからの要求を CS_EVENT_MTD_REQUEST イベントとして
  受け取ります。カードサービスは、要求の内容をイベントコールバックの引き
  数の mtdrequest 変数に入れて渡します。データをホストと受け渡しする要求
  については、ホストのバッファのアドレスが buffer 変数に渡されます。

  mtd_request_t 構造体の定義は次のとおり:

       typedef struct mtd_request_t {
               u_long          SrcCardOffset;
               u_long          DestCardOffset;
               u_long          TransferLength;
               u_long          Function;
               u_long          MediaID;
               u_long          Status;
               u_long          Timeout;
       } mtd_request_t;

  Function の変数はビットマップで、この要求で実行される動作を示していま
  す。

     MTD_REQ_ACTION
        MTD_REQ_ERASE, MTD_REQ_READ, MTD_REQ_WRITE, MTD_REQ_COPY のいず
        れか。

     MTD_REQ_NOERASE
        ブロックの境界と大きさがにぴったりはまるような書込みコマンドのと
        き、消去が不要なことを示します。

     MTD_REQ_VERIFY
        書き込み確認(verify) を指定します。

     MTD_REQ_READY
        この要求が、前回の要求がカードが準備完了を返すまで延期された後の
        再試行であることを示します。

     MTD_REQ_TIMEOUT
        この要求が、前回の要求が時間切れで延期された後の再試行であること
        を示します。

     MTD_REQ_FIRST
        この要求が、一連の要求の最初のものであることを示します。

     MTD_REQ_LAST
        この要求が、一連の要求の最後のものであることを示します。

     MTD_REQ_KERNEL
        読み書きコマンドのホストバッファが、ユーザメモリでなくカーネルメ
        モリ中にあることを示します。

  MediaID 変数は、このメモリ範囲を表わすために RegisterMTD 要求の中で指
  定された値です。Status 変数は、デバイスが何らかの処理を実行中で要求に
  応えることができなかったことを表わすために MTD が使います。MTD 要求
  は、通常は封鎖しません。要求が通常は封鎖するような場合でも、実際には封
  鎖せず、エラーコードとして CS_BUSY を返し、Status に次のいずれかの値を
  設定するはずです。訳注:「封鎖」は「block」の訳語です。「塊」の意味の
  「ブロック」 (「データブロック」など) との混同を避けるために使っていま
  す。使用例:宇津宮孝一・福田晃共訳「オペレーティングシステムの概念」
  (1987年・倍風館)

     MTD_WAITREQ
        現在実行中の別の要求の処理が正常終了した後に、要求を再試行すべき
        であることを示します。

     MTD_WAITTIMER
        timeout 変数で示される時間が経過した後に、要求を継続すべきである
        ことを示します。

     MTD_WAITRDY
        カードが準備完了状態になるか,あるいは timeout 変数で示される時
        間が経過するか、どちらかが先に起った後に、要求を継続すべきである
        ことを示します。

     MTD_WAITPOWER
        ソケットの電源の供給に影響する何事かが起った後に、要求を再試行す
        べきであることを示します。

  MTD_WAITTIMER と MTD_WAITRDY では、Timeout 変数の値はミリ秒単位のタイ
  ムアウトの時間です。

  6.2.  MTD 支援関数

  MTD はカードサービスが発生する要求を処理するので、MTD のイベントハンド
  ラから安全に実行できるカードサービス呼び出しの種類には制限があるかもし
  れません。 MTD の支援関数は、MTD が必要とするかもしれないが通常のカー
  ドサービス呼び出しを使って実現するとすると扱いにくいであろう特別なサー
  ビスを、限定されたセットとして提供します。 Linux における PCMCIA の実
  装では、ほとんどのカードサービス呼び出しは MTD から安全に呼び出すこと
  ができますが、互換性のために MTD の支援インターフェイスが含まれていま
  す。

  #include "cs_types.h"
  #include "cs.h"
  #include "bulkmem.h"

  int MTDHelperEntry(int subfunc, void *arg1, void *arg2);

  6.2.1.  MTDRequestWindow, MTDReleaseWindow

       int MTDHelperEntry(MTDRequestWindow, client_handle_t *handle, win_req_t *mod);
       int MTDHelperEntry(MTDReleaseWindow, window_handle_t handle);

  These services are identical to the standard Card Services
  RequestWindow and ReleaseWindow calls.

  6.2.2.  MTDModifyWindow

       int MTDHelperEntry(MTDModifyWindow, memory_handle_t handle, mtd_mod_req_t *mod);

  mtd_mod_req_t の構造体は次のとおり:

       typedef struct mtd_mod_req_t {
               u_long          Attributes;
               u_long          AccessSpeed;
               u_long          CardOffset;
       } mtd_mod_req_t;

  MTDModifyWindow は、通常の ModifyWindow と MapMemPage の呼出しを使うの
  と本質的に同じです。

  Attributes で指定できる内容は次のとおり。:

     WIN_MEMORY_TYPE
        WIN_MEMORY_TYPE_CM で一般メモリを示すか、または
        WIN_MEMORY_TYPE_AM で属性メモリを示します。

     WIN_USE_WAIT
        コントローラがカードの MWAIT 信号を監視する必要があることを示し
        ます。

  MTDModifyWindow で設定された領域は常に使用可能であり、16 ビットのデー
  タ幅を持ちます。

  戻り値 :

     CS_BAD_HANDLE
        メモリハンドルが不正です。

  6.2.3.  MTDSetVpp

       int MTDHelperEntry(MTDSetVpp, client_handle_t client, mtd_vpp_req_t *req);

       typedef struct mtd_vpp_req_t {
               u_char          Vpp1, Vpp2;
       } mtd_vpp_req_t;

  MTDSetVpp はソケットのプログラム電圧を変更します。Vpp1 と Vpp2 は 1/10
  ボルト単位で与えられます。現在のところ、Vpp1 と Vpp2 は常に等しくなけ
  ればなりません。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが不正です。

     CS_BAD_VPP
        指定された Vpp が正しくないか、または Vpp1 と Vpp2 が等しくな
        い。

  6.2.4.  MTDRDYMask

       int MTDHelperEntry(MTDRDYMask, client_handle_t client, mtd_rdy_req_t *req);

       typedef struct mtd_rdy_req_t {
               u_long          Mask;
       } mtd_rdy_req_t;

  MTDRDYMask は、CS_EVENT_READY_CHANGE イベントを使用できるようにするか
  どうかを選択します。クライアントは、RegisterClient 又は SetEventMask
  のいずれかの呼出しを使って、カードサービスに対してこれらのイベントを受
  け取ることを表明しておかなければなりません。Mask 引き数の
  CS_EVENT_READY_CHANGE ビットがセットされていると、イベントの変更ができ
  るようになります。

  戻り値 :

     CS_BAD_HANDLE
        クライアントハンドルが不正です。

  7.  ドライバサービスインタフェース

  ドライバサービスは、カードサービスのクライアントドライバと cardmgr の
  ようなユーザモードのユティリティを結び付けます。カードサービスの「スー
  パクライアント」といってもよいでしょう。ドライバサービスは、
  BindDevice 関数を使って、他のクライアントドライバをそれぞれの PCMCIA
  カードと結び付けます。他のクライアントとは異なり、ドライバサービスは、
  カードの抜き差しが行われても、ずっと全部のソケットに拘束されたまま残り
  ます。

  7.1.  他のクライアントドライバへのインタフェース

  ドライバサービスは、導入されていてソケットに結合できる状態になっている
  すべてのクライアントドライバを把握しています。クライアントドライバに
  は、デバイスの「実体」の作成と削除をするための項目がなければなりませ
  ん。ここで言うデバイスの実体とは、ある PCMCIA カードを制御するために必
  要なすべてを意味します。

  各デバイスは、cs_types.h に定義された特別な型 dev_info_t を持つ、ユニ
  ークな1 6 文字のタグで識別されます。各デバイスの実体は、 dev_link_t 構
  造体で記述されます。

  7.1.1.  dev_link_t 構造体

  dev_link_t のデータ構造体は次のとおり:

       #include "ds.h"

       typedef struct dev_node_t {
               char                    dev_name[8];
               u_char                  major, minor;
               struct dev_node_t       *next;
       }

       typedef struct dev_link_t {
               dev_node_t              *dev;
               u_long                  state, open;
               struct wait_queue       *pending
               struct timer_list       release
               client_handle_t         handle;
               io_req_t                io;
               irq_req_t               irq;
               config_req_t            conf;
               window_handle_t         win;
               void                    *priv;
               struct dev_link_t       *next;
       } dev_link_t;

  dev_link_t 構造体の dev 変数はリンクリストの dev_node_t 構造体をポイン
  トしています。dev_node_t の dev_name 変数は、ドライバによって、このデ
  バイスをアクセスするためのファイル名が書き込まれます(可能な場合のみ)。
  例えば、serial_cs は「ttyS1」の様な名前を使います。major と minor の変
  数は、このデバイスをアクセスするためのメジャー番号とマイナー番号です。
  ドライバサービスは、これらの変数を DS_GET_DEVICE_INFO ioctl でユーザモ
  ードプログラムに返します。

  dev_link_t の state 変数は、現在のデバイスの状態を把握するために使われ
  ます。次のフラグが定義されています。:

     DEV_PRESENT
        カードが存在することを示します。このビットは、ドライバのイベント
        ハンドラによって、カードの抜差しのイベントに対応してセットまたは
        クリアされます。

     DEV_CONFIG
        カードが設定済みであることを示します。

     DEV_CONFIG_PENDING
        カードの設定作業が実行中であることを示します。

     DEV_SUSPEND
        カードが一時的に使用できないことを示します。

     DEV_BUSY
        入出力動作が実行中であることを示します。このビットは、アクセスの
        衝突を防ぐためのインターロックとして使うこともできます。

     DEV_STALE_CONFIG
        ドライバによっては、実行中のカードが抜かれた時には、そのカードに
        対応するすべてのデバイスが閉じるまでは、ソケットを解放すべきでは
        ありません。このフラグは、デバイスがク閉じた時にソケットを解放し
        なければならないことを示します。

     DEV_STALE_LINK
        ドライバの実体は、そのすべての PCMCIA リソースが解放されるまで削
        除されてはなりません。このフラグは、ソケットが解放されたらすぐに
        ドライバの実体が削除されなければならないことを示します。

  open 変数は、このデバイスが何重に使われているかを数えます。デバイス
  は、このカウントがゼロになるまで解放されてはなりません。 pending 変数
  は、このデバイスを使うために待っているプロセスの待ち行列を管理するため
  に使うことができます。

  release 変数は、カードが抜かれた時に、デバイスのシャットダウン処理を予
  定に入れるために使われます。カードの引抜きのイベントは高い優先度で実行
  されなければなりません。ドライバのイベントハンドラは、通常デバイス状態
  の DEV_PRESENT ビットをリセットし、その時シャットダウン処理が後で実行
  されるように予定することでイジェクトの処理をします。

  handle、io、irq、confおよび win の各変数は、通常の PCMCIA 入出力カード
  を組み込むために必要な普通の PCMCIA データ構造に対応します。

  priv 変数は、デバイスを管理するために必要などんな私的なデータ構造の目
  的のためにでも使うことができます。next 変数は、複数の実体を扱うことの
  できるドライバで、dev_link_t 構造体の結合リストを作るために使うことが
  できます。

  7.1.2.  register_pcmcia_driver

       int register_pcmcia_driver(dev_info_t *dev_info,
                                  dev_link_t *(*attach)(void),
                                  void (*detach)(dev_link_t *));

  register_pcmcia_driver は、ドライバサービスに、クライアントドライバが
  存在していてソケットに結び付けられる状態であることを知らせます。ドライ
  バサービスがこのドライバの dev_info 文字列に等しい DS_BIND_REQUEST
  ioctl を受け取ると、ドライバサービスはドライバの attach() 関数を呼び出
  します。DS_UNBIND_REQU EST ioctl を受け取ったときは、detach() を呼び出
  します。

  7.1.3.  unregister_pcmcia_driver

       int unregister_pcmcia_driver(dev_info_t *dev_info);

  この関数は、ドライバサービスに、指定されたクライアントドライバにはソ
  ケットを結び付けてはならないことを知らせます。

  7.2.  ユーザモードの PCMCIA ユティリティとのインタフェース

  ドライバサービスは、ユーザモードの PCMCIA ユティリティと通信するために
  疑似デバイスを作ります。このデバイスのメジャー番号は動的に選ば
  れ、PCMCIA ユティリティは /proc/devices を読んでその値を得なければなり
  ません。マイナー番号は 0 から始まるソケットの番号に対応します。

  ただ一つのプロセスだけが、あるソケットを読書きのためにオープンすること
  ができます。他のプロセスは、読出し専用モードでのみ、このソケットをオー
  プンできます。読出しのみの接続では、一部の ioctl 機能だけが使えます。
  読書き両方の接続では、すべての ioctl 機能が使え、カードサービスからの
  イベントの通知を受け取ることができます。

  7.2.1.  カードサービスのイベント通知

  ドライバサービスは、イベントの通知のために read() と select() の関数を
  実装しています。ある PCMCIA デバイスから読出しを行うと、前回の read()
  以降ドライバサービスが受信したすべてのイベントが unsigned long の値と
  して返されます。もしイベントが何も発生していなければ、イベントが発生す
  るまで、呼出しは封鎖します。select() を使って、複数のソケットの新規の
  イベントを監視することができます。

  ドライバサービスは、次のイベントを監視します。:
  CS_EVENT_CARD_INSERTION, CS_EVENT_CARD_REMOVAL,
  CS_EVENT_RESET_PHYSICAL, CS_EVENT_CARD_RESET と
  CS_EVENT_RESET_COMPLETE.

  7.2.2.  ioctl の説明

  ほとんどのドライバサービスの ioctl の動作は、カードサービスの関数に直
  接対応します。ioctl の呼出しは、次の形式です。:

       int ioctl(int fd, int cmd, ds_ioctl_arg_t *arg);

  ds_ioctl_arg_t の構造体は次のとおり:

       typedef union ds_ioctl_arg_t {
               servinfo_t      servinfo;
               adjust_t        adjust;
               config_info_t   config;
               tuple_t         tuple;
               tuple_parse_t   tuple_parse;
               client_req_t    client_req;
               status_t        status;
               conf_reg_t      conf_reg;
               cisinfo_t       cisinfo;
               region_info_t   region;
               bind_info_t     bind_info;
               mtd_info_t      mtd_info;
       } ds_ioctl_arg_t;

  次の ioctl のコマンドは、対応するカードサービスの関数を実行します。:

     DS_GET_CARD_SERVICES_INFO
        CardServices(GetCardServicesInfo, ..., &arg->servinfo) を呼び出
        します。

     DS_ADJUST_RESOURCE_INFO
        CardServices(AdjustResourceInfo, ..., &arg->adjust) を呼び出しま
        す。

     DS_GET_CONFIGURATION_INFO
        CardServices(GetConfigurationInfo, ..., &arg->config) を呼び出し
        ます。

     DS_GET_FIRST_TUPLE
        CardServices(GetFirstTuple, ..., &arg->tuple) を呼び出します。

     DS_GET_NEXT_TUPLE
        CardServices(GetNextTuple, ..., &arg->tuple) を呼び出します。

     DS_GET_TUPLE_DATA
        CardServices(GetTupleData, ..., &arg->tuple_parse.tuple) を呼び
        出します。タプルデータが arg->tuple_parse.data の中に返ります。

     DS_PARSE_TUPLE
        CardServices(ParseTuple, ..., &arg->tuple_parse.tuple,
        &arg->tuple_parse.parse) を呼び出します。

     DS_RESET_CARD
        CardServices(ResetCard, ...) を呼び出します。

     DS_GET_STATUS
        CardServices(GetStatus, ..., &arg->status) を呼び出します。

     DS_ACCESS_CONFIGURATION_REGISTER
        CardServices(AccessConfigurationRegister, ..., &arg->conf_reg)
        を呼び出します。

     DS_VALIDATE_CIS
        CardServices(ValidateCIS, ..., &arg->cisinfo) を呼び出します。

     DS_SUSPEND_CARD
        CardServices(SuspendCard, ...) を呼び出します。

     DS_RESUME_CARD
        CardServices(ResumeCard, ...) を呼び出します。

     DS_EJECT_CARD
        CardServices(EjectCard, ...) を呼び出します。

     DS_INSERT_CARD
        CardServices(InsertCard, ...) を呼び出します。

     DS_GET_FIRST_REGION
        CardServices(GetFirstRegion, ..., &arg->region) を呼び出します。

     DS_GET_NEXT_REGION
        CardServices(GetNextRegion, ..., &arg->region) を呼び出します。

  次の ioctl のコマンドは、特別なドライバサービスの関数を呼び出します。
  これらのコマンドは、bind_info_t 構造体に作用します。:

       typedef struct bind_info_t {
               dev_info_t              dev_info;
               u_char                  function;
               struct dev_info_t       *instance;
               char                    name[8];
               u_char                  major, minor;
               void                    *next;
       } bind_info_t;

     DS_BIND_REQUEST
        このコマンドは、ソケットをクライアントドライバに接続します。指定
        されたデバイス識別子の dev_info が、登録されたドライバのリストか
        ら検索されます。もしこのカードが多機能カードの場合は、 function
        変数がどのカード機能を接続するかを指定します。もしドライバが見つ
        かると、ドライバはこのソケットと機能を、 BindDevice を呼び出すこ
        とによって接続されます。その後、ドライバサービスはドライバの
        attach() 項目を呼び出してデバイスの実体を作成します。新しい
        dev_link_t が instance の中に返されます。

     DS_GET_DEVICE_INFO
        このコマンドは、instance が指し示す dev_link_t 構造体から、
        dev_name、major、 minor の項目を検索します。

     DS_UNBIND_REQUEST
        このコマンドはドライバと instance を指定した detach() 関数を呼び
        出してデバイスをシャットダウンさせます。

  最後に DS_BIND_MTD 要求は、引き数に mtd_info_t の型をとります。:

       typedef struct mtd_info_t {
               dev_info_t      dev_info;
               u_long          Attributes;
               u_long          CardOffset;
       } mtd_info_t;

  この呼び出しは、dev_info によって識別される MTD と Attributes と
  CardOffset によって記述されるメモリ範囲を関連づけます。 Attributes と
  CardOffset は、カードサービスの BindMTD の呼出しのときと同じ意味です。
  8.  カードサービスクライアントドライバの解剖

  Linux PCMCIA パッケージのそれぞれの版は、最初から新規にドライバを書け
  るように良く文書化された``雛型''のクライアントドライバと一緒に提供して
  います。 modules/skeleton.c に置いています。

  8.1.  モジュールの初期化とリセット

  全てのローダブルモジュールは init_module() と cleanup_module() 関数を
  備えなければいけません。それはモジュールを着脱するときにモジュールを支
  援するプログラムが必要とするからです。PCMCIA クライアントドライバの初
  期化関数は register_pcmcia_driver() 呼び出し経由でドライバサービスに
  よってドライバを登録します。再初期化(cleanup) 関数は
  unregister_pcmcia_driver() を使用してドライバサービスによって登録解除
  します。ドライバによっては、再初期化関数はシャットダウン時に存在するデ
  バイスの構造体を解放する為にも呼ばれるかもしれません。

  8.2.  *_attach() と *_detach() 関数

  *_attach() 関数はドライバの ``実体'' を作成し、1つの PCMCIA カードの管
  理に必要なデータ構造体の設定を行なう役目があります。*_attach() 関数は
  dev_link_t 構造体の割り当てと初期化を行ない、RegisterClient を呼び出し
  てカードサービスとの結合を確立します。RegisterClient は新しく出来た
  dev_link_t 構造体へのポインタを返し、作成できなかった時は NULL を返し
  ます。

  *_detach() 関数は以前に発行した *_attach が作成したドライバの実体を削
  除します。また、カードサービスとの結合も DeregisterClient を使って解除
  します。

  *_attach() 関数は DS_BIND_REQUEST ioctl() で一致するドライバが識別で
  き、割り付けがうまくいった時にドライバサービスによって呼ばれます。
  *_detach() 関数は DS_UNBIND_REQUEST ioctl() を呼ぶことに応答し起動しま
  す。

  8.3.  *_config() と *_release() 関数

  *_config() 関数はカードに対する入出力の準備の為に呼ばれます。殆んどの
  ドライバは詳細な情報はカード自身から読み出しますが、どのようにデバイス
  を設定するかの最小限の知識はドライバに組み込まれています。例えば、シリ
  アルカードのドライバはカードの CFTABLE_ENTRY タプルから一致する入出力
  ポートの基底アドレスと一致する設定指標を読み込みますが、 CIS 内の割り
  込み情報は無視します。*_config 関数はカードの CIS の関連する部分を解析
  します。そして RequestIO, RequestIRQ や RequestWindow を呼び出せます。
  それから RequestConfiguration を呼びます。

  カードの設定がうまくいったら、*_config() ルーチンが dev_link_t 構造体
  の dev_name, major と minor 変数に書き込みます。これらの変数は
  DS_GET_DEVICE_INFO ioctl () の応答としてドライバサービスがユーザプログ
  ラムに返します。

  *_release() 関数は以前に呼んだ *_config() が割り当てたリソースを解放
  し、デバイスの dev_name 変数を空白にします。

  *_config() と *_release 関数は通常カード状態の変更イベントまたはタイマ
  ー割り込みに反応して呼ばれます。この時、これらの関数はスリープ出来な
  く、他のカーネル関数から呼ばれないように遮断しておきます。

  8.4.  PCMCIA イベントハンドラ

  *_event() 関数はカードサービスからカード状態次変更イベントを通知する為
  に呼ばれます。

  8.5.  ロックと同期について

  設定したソケットは全ての関連したデバイスが閉じられた時にのみ解放されま
  す。ソケットの解放はソケットのシステム資源を他のデバイスで使用出来るよ
  うにします。解放された資源が元のデバイスで入出力に使用している場合は、
  元のドライバは新しいデバイスを使用してします。

  ドライバの実体は一致するソケットの構成が解放された後のみ解放されます。
  カードサービスは DeregisterClient が成功する為にはクライアントが明らか
  に割り当てた資源を解放する必要があります。

  全てのローダブルモジュールは安全にモジュールを解放する時にシステムが使
  用する ``使用回数(use count)'' を持っています。PCMCIA クライアントドラ
  イバの慣習はデバイスをオープンすると使用回数を増加させ、デバイスをクロ
  ーズすると使用回数を減少させます。従ってドライバを解放するには全ての関
  連するデバイスは閉じている必要があります。特に、ソケットが接続している
  時にドライバを解放出来ます。モジュール再初期化プログラムは適切な解放で
  きる既に割当済みの資源を必要とします。これは使用回数がゼロで、全てのデ
  バイスが閉じていて、つまり全てのソケットが解放できる状態で全てのデバイ
  スが外せる場合に安全な方法です。

  デバイスが開いている状態で *_release() 関数が呼ばれたら、デバイス状態
  の DEV_STALE_CONFIG フラグが設定され close() 関数が呼ばれた時にデバイ
  スを解放するように通知します。構成したデバイスを*_detach() 関数で呼び
  出したら、DEV_STALE_LINK フラグは *_release() 関数が呼ばれた時に実体が
  解放されるように通知するように設定されます。

  8.6.  現有の Linux のドライバで PCMCIA デバイスをアクセスする方法

  現在の PCMCIA クライアントドライバは現有の Linux のドライバをデバイス
  の入出力操作を行ないます。カードサービスクライアントモジュールはカード
  の構成とカード状態の変更イベントの監視を行ないますが、通常の ISA バス
  のカードのドライバと互換性のある入出力を行ないます。いくつかの場合で
  は、普通のドライバを変更無しに使う事が出来ます。しかしながら、活線抜去
  やパワーマネージメントのような PCMCIA の機能はすべてはサポートされてい
  ませんので、PCMCIA クライアントプログラムとデバイス入出力プログラムの
  間で通信をする必要があります。

  殆んどのドライバはブート時にデバイスを探知するのと着脱出来るデバイスを
  扱うように設計されています。ドライバのモジュール化の副作用は通常着脱可
  能なデバイスを扱うのにモジュラー化したドライバは簡単に受け入れられると
  いうことです。

  重要な事は、適切でない時にデバイスを取り去ってしまいデバイスドライバが
  使えなくなる事です。最善の方法はドライバが入出力操作や入出力割り込みを
  行なう前にデバイスを事前に確認する事です。デバイスの状態の確認の繰返し
  は時間切れになってしまい、結局デバイスが応答しない場合は終了します。

  9.  さらなる情報はどこにあるか?

  Michael Johnson が書いた Linux カーネルハッカーの手引き (Linux Kernel
  Hackers' Guide) は Linux のデバイスドライバを書く為の良い一般的な情報
  源です。一般の Linux の FTP サイトにまとめられた Linux 文書とともにお
  いてあります。

  本物の PCMCIA 標準は PCMCIA 協会それ自身だけが発行してますが途方もなく
  高価です。新しい PC Card 95 標準は 399 ドルですが古い 2.1 標準はかなり
  値引きが出来ると思います。

       Personal Computer Memory Card International Association
       1030 East Duane Avenue, Suite G
       Sunnyvale, CA 94086 USA
       (408) 720-0107, (408) 720-9416 FAX, (408) 720-9388 BBS
       http://www.pc-card.com

  その代わりにMichael Mori が書いた PCMCIA 開発者の手引き (PCMCIA
  Developer's Guide) は Sycard Technology から発行され、 ISBN
  0-9640342-1-2 で、およそ 89.95 ドルです。

       Sycard Technology
       1180-F Miraloma Way
       Sunnyvale, CA 94086 USA
       (408) 749-0130, (408) 749-1323 FAX

  Dana Beatty, Steven Kipisz と Brian Moore が書いた PCMCIA ソフトウェア
  開発者のハンドブック (PCMCIA Software Developer's Handbook) はPCMCIA
  標準の概要とクライアントドライバの書き方の説明をしています。ま
  た、Linux PCMCIA プログラマの手引きを付録に添付しています。発行は
  Peer-to-Peer Communications で ISBN 1-57398-010-2 です。

  Larry Levine はより一般的な PCMCIA への紹介文である 1995 年の夏に書店
  に並んだ PCMCIA 入門(PCMCIA Primer)を書いています。 M & T Books が出版
  し、ISBN 1-55828-437-0 です。

  各種の PCMCIA 制御装置に関するプログラム情報は該当するチップベンダーか
  ら取り寄せましょう。:

       Intel Corporation
       (800) 628-8686

       Cirrus Logic
       (510) 623-8300

       Vadem
       (408) 943-9301

       Databook Inc.
       (716) 889-4204

  [EOF]

一覧に戻る
グリーンネット・トップページへ戻る

http://www.green.ne.jp/