JP2016509714A - ハードウェア・デバイス用ソフトウェア・インターフェース - Google Patents

ハードウェア・デバイス用ソフトウェア・インターフェース Download PDF

Info

Publication number
JP2016509714A
JP2016509714A JP2015551765A JP2015551765A JP2016509714A JP 2016509714 A JP2016509714 A JP 2016509714A JP 2015551765 A JP2015551765 A JP 2015551765A JP 2015551765 A JP2015551765 A JP 2015551765A JP 2016509714 A JP2016509714 A JP 2016509714A
Authority
JP
Japan
Prior art keywords
hardware
act
driver
generating
code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2015551765A
Other languages
English (en)
Other versions
JP2016509714A5 (ja
Inventor
ウェインズバーグ，ヤーロン
ユ，ジンソーン
グラバーニク，マキシム
マッサレンティ，ダヴィデ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2016509714A publication Critical patent/JP2016509714A/ja
Publication of JP2016509714A5 publication Critical patent/JP2016509714A5/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Computer Security & Cryptography (AREA)

Abstract

ハードウェアとインターフェースするためにデバイス・ドライバーと共に使用されるコードを自動的に生成する。本方法は、ハードウェア・デバイスのハードウェア・レジスターまたは共有メモリー構造の内少なくとも１つを含む、ハードウェア・デバイスの機械読み取り可能記述を受けるアクトを含む。更に、本方法は、ハードウェア・デバイスと共に使用されることになるオペレーティング・システムを決定するアクトも含む。更に、本方法は、決定したオペレーティング・システムに特定的なハードウェア・ドライバーのために、ハードウェア・デバイス用コードを自動的に生成するために、コード生成ツール上で機械読み取り可能記述を処理するアクトを含む。【選択図】図５

Description

[0001] コンピューターおよび計算システムは、現代生活の殆どあらゆる面に影響を及ぼしている。コンピューターは、仕事、リクリエーション、健康管理、輸送、娯楽、家事管理等に総合的に関わっている。
[0002] 汎用計算システムは、デバイス・ドライバーとして知られるコードを使用することによって、多数のデバイスを利用することができる。デバイス・ドライバーは、ハードウェアまたは他のデバイスを、ＣＰＵレジスター、システム・メモリー・レジスター等のような、システム・リソースにインターフェースする１つの方法として機能する。デバイス・ドライバーは、通例、特権モードであるカーネル・モードで実行する。具体的には、カーネル・モードでは、ドライバー・コードはあらゆるメモリー・アドレスにアクセスし、あらゆるシステム・レベルのコンポーネントを制御することができる。したがって、欠陥のあるドライバーまたは悪意のドライバーは、計算システムの完全性を容易に損ない、クラッシュまたはデーター変転(corruption)に至るおそれがある。
[0003] つまり、デバイス・ドライバーは安全ではない。オブジェクト指向設計方法論、言語型−安全および静止コード検証は、高度プラットフォーム（例えば、いわゆるクラウド）および開発環境へのそれらの道を見出したが、デバイス・ドライバーは相変わらず安全でない言語（例えば、Ｃ／Ｃ＋＋）を使用して開発されており、型なし、非オブジェクト指向、およびエラーが起こりがちなインターフェースを使用してアクセスされる。殆どのデバイス・ドライバーは、未だカーネル・モードで実行され、１つのソフトウェア・バグがシステム障害の原因となる潜在的可能性が高くなる。更に、いずれのドライバーもユーザー・モードで実装される限り、高スループットおよび低レイテンシ・デバイスのためにドライバーを使用することはできない。何故なら、オペレーティング・システムの中には、ハードウェアの割り込みを効率的にユーザー・モード・プロセスに伝えることができないものがあるからである。他のオペレーティング・システムでは、ユーザー・モード・ドライバーの性能は、カーネル・モード・ドライバーよりも遙かに劣る。
[0004] ハードウェア製造業者は、通例、ハードウェアを自由形態のハードウェア仕様で記述する。ドライバーの開発者はこれらの仕様を使用して、ハードウェア・アクセス・レイヤを開発する。このレイヤは、ドライバーがデバイス・レジスターおよび共有メモリーと相互作用することを可能にする。このレイヤを開発することは、厄介でエラーが起こりがちである。何故なら、これは仕様の品質および開発者の経験に依存するからである。殆どの場合、このレイヤは、オペレーティング・システムに依存し、他のプラットフォームが使用することはできない。
[0005] 本明細書において特許請求する主題は、欠点を解決する実施形態にも、以上で説明したような環境のみで動作する実施形態にも限定されない。むしろ、この背景は、本明細書において説明する実施形態を実施することができる技術分野の一例を例示するために提示されたに過ぎない。
[0006] 本明細書において例示する一実施形態は、計算環境において実施される方法を含み、ハードウェア・デバイスと相互作用するためにデバイス・ドライバーによって使用されるコードを自動的に生成するアクトを含む。この方法は、ハードウェア・デバイスの機械読み取り可能記述を受けるアクトを含み、ハードウェア・デバイスのハードウェア・レジスターまたは共有メモリー構造の内少なくとも１つを含む。更に、この方法は、ハードウェア・デバイスと共に使用しようとするオペレーティング・システムを決定するアクトも含む。更に、この方法は、コード生成ツール上で機械読み取り可能記述を処理して、決定されたオペレーティング・システムに特定的なハードウェア・デバイスのために、ハードウェア・ドライバーのコードを自動的に生成するアクトも含む。
[0007] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として使用されることを意図するのでもない。
[0008] 以下に続く説明において、追加の特徴および利点を明記する。これらは、部分的にその説明から自明であり、本明細書における教示の実施によって習得することができる。本発明の特徴および利点は、添付する特許請求の範囲において特定的に指摘される手段(instrument)および組み合わせによって、実現し習得することができる。本発明の特徴は、以下の説明および添付する特許請求の範囲から一層明白になり、または以下に明記する本発明の実施によって習得することができる。
[0009] 以上で列挙したおよびその他の利点および特徴を得ることができるやり方を説明するために、以上で端的に説明した主題の更に特定的な説明を、添付図面に示す具体的な実施形態を参照して行う。これらの図面は典型的な実施形態のみを描いたのであり、したがって範囲を限定するように解釈すべきでないことを理解した上で、添付図面の使用により、更に具体的にそして詳細に実施形態について説明する(described and explained)。
図１は、デバイス・ハードウェア、および自動デバイス・ハードウェア抽象レイヤ・インターフェースの生成を示す。 図２は、階層的ドライバーの生成を示す。 図３は、バス・ドライバーのフレームワークを示す。 図４は、ドライバー割り込みおよびデバイス通信を示す。 図５は、デバイス・ドライバーにコードを自動的に生成する方法を示す。 図６は、ハードウェア・ドライバーに制限を強制する方法を示す。 図７は、高スループットおよび低レイテンシ・デバイスをサポートすることができる、安全なドライバーを実現する方法を示す。
[0017] 本明細書において開示する実施形態は、全てのデバイス・タイプのために、高性能ユーザー・モードおよびタイプ・セーフ・ドライバー(type safe driver)の開発を容易にする多数の技法を含むことができる。これらのドライバーは、他のオペレーティング・システムに存在する旧来のカーネル・モード・デバイス・ドライバーに比肩する性能を実現する。
[0018] ある実施形態は、自動生成デバイス・ドライバー・ハードウェア抽象レイヤを実現することができる。図１に示すように、ハードウェア・デバイス１０２は、ＣＰＵ１０８におけるレジスター１０６およびシステム・メモリー１１２における共有メモリー１１０を使用して、計算システム１０４とインターフェースする。ハードウェア・デバイスは、通例、複数組のレジスター１０６における特定のレジスター、および特定のメモリー相互作用(memory interaction)とインターフェースするように、静的に構築される。システム１０４、レジスター１０６、および共有メモリー１１０がハードウェア・デバイス１０２と適正にインターフェースすることを保証するために、システム・ハードウェアとデバイス・ハードウェアとの間でマッピングを行うドライバー１１４が使用される。ドライバー１１４は、通例、製造業者が提供する文書による仕様を使用することによって、手作業で開発される。
[0019] ハードウェア製造業者は、通例、自由形態のハードウェア仕様(free form hardware specifications)でハードウェアを記述する。ドライバーの開発者は、これらの仕様を使用して、ハードウェア・アクセス・レイヤを開発する。注記したように、このレイヤは、直接メモリー・アクセス（ＤＭＡ）を使用することによってというようにして、ドライバーがデバイス・レジスターおよび共有メモリーと相互作用することを可能にする。このレイヤを開発するのは、厄介でエラーが起こりがちである。何故なら、これは仕様の品質および開発者の経験に依存するからである。殆どの場合、このレイヤは、オペレーティング・システムに依存し、他のプラットフォームが使用することはできない。
[0020] 本明細書におけるある実施形態は、ハードウェア・アクセス・レイヤ仕様をその実現(implementation)から分離するハードウェア抽象メカニズムを実現することによって、ドライバーの開発を簡略化する。機械読み取り可能ハードウェア仕様１１６は、デバイス販売業者によって提供することができる。この機械読み取り可能ハードウェア仕様は、コード生成ツール１１８によって処理される。コード生成ツール１１８は、１つ以上の異なるオペレーティング・システムの対するオペレーティング・システム・コンテキストを有し、したがって機械読み取り可能ハードウェア仕様１１６を処理することによって、ハードウェア・デバイス・インターフェース・レイヤを自動的に作成することができる。このように、機械読み取り可能ハードウェア仕様１１６は、多数の異なるオペレーティング・システムのために、そして種々の異なるプログラミング言語を使用して、ハードウェア・デバイス・インターフェース・レイヤ１１５−１、１１５−２、．．．、１１５−ｎを作成するために再使用することができる。この方式は、ドライバー開発を大幅に簡略化し、正しくないハードウェア・アクセスによって生ずるエラーの量を低減する。機械読み取り可能ハードウェア仕様１１６は、Ｃ＃のような単純な言語で書くことができ、検査によって容易に有効性を判断することができる。
[0021] このように、開発者またはハードウェア製造業者は、ハードウェア−ソフトウェア・インターフェース言語を使用して、デバイス１０２のハードウェア・レジスターおよび共有メモリー構造（ホスト・メモリーにおける）を記述することができる。この目的のために、開発者は文書によるハードウェア仕様を参照する。尚、ハードウェア設計者またはハードウェア販売業者も、機械読み取り可能ハードウェア仕様１１６のハードウェア−ソフトウェア・インターフェース記述を提供できることを注記しておく。特に、ドライバー開発者は、ハードウェア−ソフトウェア・インターフェース言語を使用して機械読み取り可能ハードウェア仕様１１６を定めるために、ハードウェア記述フェーズに関与する必要はない。第２フェーズにおいて、ハードウェア記述はコード生成ツール１１８によって処理される。コード生成ツール１１８は、ハードウェア−ソフトウェア・インターフェース・プロセッサー１２０を含む。
[0022] ハードウェア−ソフトウェア・インターフェース・プロセッサー１２０は、以下で例示するように、種々のソフトウェア・ドライバー・モジュールを生成することができる。
[0023] ハードウェア−ソフトウェア・インターフェース・プロセッサー１２０は、レジスターの読み取り／書き込みを行い、それらのフィールドを解釈するためのハードウェア・アクセス・メソッドを生成することができる。例えば、機械読み取り可能ハードウェア仕様１１６に基づいて、コード生成ツール１１８は、１組のレジスター１０６におけるどのレジスターが、ハードウェア・デバイス１０２と通信するために使用されるか決定することができる。これらのレジスターにアクセスするためのメソッドを生成することができ、各レジスターの目的および各レジスターにおけるデーターの解釈を示すためにハードウェア・デバイス１０２を制御することを望むアプリケーションにソフトウェア・インターフェースを提供するために使用することができる。
[0024] ハードウェア−ソフトウェア・インターフェース・プロセッサー１２０は、共有構造フィールドの読み取り／書き込みを行うメソッドを生成することができる。例えば、機械読み取り可能ハードウェア仕様１１６に基づいて、コード生成ツール１１８は、ドライバー・ソフトウェア・モジュールにおいて、ハードウェア・デバイス１０２によって使用される共有メモリー１１０の部分を識別することができる。これによって、ソフトウェア・アプリケーションがドライバー１１４を使用して、ハードウェア・デバイス１０２によって使用される共有メモリー１１０の部分と通信することが可能になる。
[0025] ハードウェア−ソフトウェア・インターフェース・プロセッサー１２０は、ハードウェア−ソフトウェア・インターフェース記述において表現されるハードウェア・インターフェース・エンティティのために、メモリー・アロケーター(memory allocator)を生成することができる。例えば、機械読み取り可能ハードウェア仕様１１６に基づいて、コード生成ツール１１８は、どのハードウェア・インターフェースがハードウェア・デバイス１０２に含まれるのか把握する。したがって、ハードウェア・インターフェース・レイヤ１１５は、システム・メモリー１１２におけるメモリーをハードウェア・インターフェースの使用のために割り当てるメモリー・アロケーターを含むように、自動的に生成することができる。
[0026] ハードウェア−ソフトウェア・インターフェース・プロセッサー１２０は、ハードウェア・インターフェース・エンティティを解釈し追跡するログ・モジュールを生成することができる。例えば、機械読み取り可能ハードウェア仕様１１６およびハードウェア・デバイス１０２のハードウェア・インターフェースの知識に基づいて、コード生成ツール１１８は、ハードウェア・デバイス１０２のハードウェア・アクションを記録するデーターを収集し記録するためにハードウェア・インターフェースを使用することができるモジュールを含むように、ハードウェア・インターフェース・レイヤ１１５を自動的に生成することができる。
[0027] ハードウェア−ソフトウェア・インターフェース・プロセッサー１２０は、ハードウェア・インターフェース・エンティティを可視化するデバッガー拡張(debugger extension)を生成することができる。例えば、機械読み取り可能ハードウェア仕様１１６およびハードウェア・デバイス１０２のハードウェア・インターフェースについての知識に基づいて、コード生成ツール１１８は、デバッギングの目的のために使用することができるハードウェア・デバイス１０２のハードウェア・アクションを記録するデーターを収集して記録するハードウェア・インターフェースを使用することができるモジュールを含むように、ハードウェア・インターエース・レイヤ１１５を自動的に生成することができる。
[0028] 以下に、ＵＳＢ ＥＨＣＩコントローラ能力レジスター(controller capability register)のハードウェア−ソフトウェア・インターフェースの見本記述を示す。
/// <summary>
/// These registers specify the limits, restrictions and capabilities of the host controller implementation.
/// </summary>
[MemoryMappedRegister(ResourceType.MemoryRange, Size = OxC)]
struct EhciCapabilityRegisters
{
/// <summary>
/// Capability Registers Length and Hci Version register combined in a single DWORD.
/// </summary>
[DataField(Offset = 0x0)] public CapLengthHCIVersion CapVer;

/// <summary>
/// This is a set of fields that are structural parameters: Number of downstream ports, etc.
/// </summary>
[DataField(Offset = 0x4)] public HCSPARAMS HCSPARAMS;

/// <summary>
/// Multiple Mode control (time-base bit functionality), addressing capability.
/// </summary>
[DataField(Offset = 0x8)] public HCCPARAMS HCCP ARAMS;
}
[0029] 注記したように、この表は、ＵＳＢ ＥＨＣＩコントローラ・レジスターの見本記述を示す。提示されたレジスターは、能力レジスターである。各レジスターは、デバイス・メモリーの基底アドレスに対してあるオフセットのところに配置される。この例では、能力レジスターは、ハードウェア−ソフトウェア・シンタックスの一部である、"MemoryMappedRegister"属性によって指定されるオフセット0xCに配置される。一旦レジスターの基底アドレスが設定されたなら、ハードウェア−ソフトウェア・インターフェースは異なるレジスター・フィールドを提示するために様々な属性を提供する。この例では、"DataField"属性は、能力レジスターの一部であるレジスターを表すために使用される。例えば、HCSPARAMSは、能力レジスター（説明したように、0xCにある）の基底アドレスからオフセット0x４に配置されたレジスターである。各データー・フィールドは、ハードウェア−ソフトウェア・インターフェース・シンタックスによって繰り返し注釈が付けられる（以下で例示する通り）。
[0030] 以下に、HCCPARAMSレジスター・フィールドのハードウェア−ソフトウェア・インターフェース記述を示す。
/// <summary> Host Controller Capability Parameters </summary>
[MemoryMappedRegister(Size = 4)]
struct HCCPARAMS
{
[ReservedBits(16, 31)] public uint Reservedl;

/// <summary>
/// EHCI Extended Capabilities Pointer (EECP).
/// </summary>
[BitField(8, 15)] public uint EECP;

/// <summary>
/// Isochronous Scheduling Threshold. Default is implementation dependent.
/// </summary>
[BitField(4, 7)] public ushort IsochronousSchedulingThreshold;

[ReservedBits(3)] public uint Reserved2;

/// <summary>
/// Asynchronous Schedule Park Capability. Default is implementation dependent.
/// </summary>
[BitField(2)] public uint AsyncSchedulePark;

/// <summary>
/// Programmable Frame List Flag. Default = Implementation dependent.
/// </summary>
[BitField(l)] public uint ProgramableFrameList;

/// <summary>
/// 64-bit Addressing Capability.
/// </summary>
[BitField(O)] public bool Bit64Addressing;
}
[0031] この表は、HCSPARAMSレジスターにどのように注釈が付けられるかを示す（以上で提示した能力レジスターの一部である）。ハードウェア−ソフトウェア・インターフェース"BitField" および"ReservedBits"属性が、開発者がレジスター・ビットに注釈を付けることを可能にする。例えば、このレジスターにおけるビット０は、デバイスが６４のアドレスをサポートするか否かを示す。開発者は、この要件を提示するために、"[(BitField(O)] public bool Bit64Addressing;"を使用する。生成されたコードは、開発者が"Bit64Addressing"にブーリアンとしてアクセスしてその値を問い合わせることを可能にする。
[0032] 以下に、HCCPARAMSフィールド値を得る／設定するために生成されたコードを示す。
/// <summary>
/// This class represents device mapped resource.
/// It uses as a container for 10 memory range and all the registers within it.
/// </summary>
readonly struct EhciCapabilityRegisters
{
public const int SizelnBytes = Oxc;
readonly IoMemory m_ioRange;
readonly int m_offset;

public EhciCapabilityRegisters(IoMemory mem, int offset = 0)
{
Contract.Requires(mem != null);
Contract.Requires(mem.Length >= SizelnBytes);
m_ioRange = mem;
m_offset = offset;
}

public ulong PhysicalAddress
{
get { return m_ioRange.PhysicalAddress.Value + (uint)m_offset; }
}

public Register32Control<CapLengthHCIVersion> CapVer
{
get { return new Register32Control<CapLengthHCIVersion>(m_ioRange, m_offset + 0x0); }
}
public Register32Control<HCSPARAMS> HCSPARAMS
{
get { return new Register32Control<HCSPARAMS>(m_ioRange, m_offset +
0x4); }
}

public Register32Control<HCCPARAMS> HCCP ARAMS
{
get { return new Register32Control<HCCPARAMS>(m_ioRange, m_offset +
0x8); }
}
}
[0033] 生成されたコードは、オペレーティング・システム特定のインターフェースを使用し、他のオペレーティング・システムにも容易に生成することができる。
[0034] 以下に、生成されたコードがデバイス・ドライバー・コードによって使用されるメソッドを例示する。
IoMemory mem = m_mappedloRange. Memory AtOffset(0,
EhciCapabilityRegisters.SizelnBytes, Access.Read);
m_capabilityRegs = new EhciCapabilityRegisters(mem);
CapLengthHCIVersion capVer = m_capabilityRegs.CapVer.Read();
EhciEvents.CapAndHci(capVer.CAPLENGTH, capVer.HCIMajorRevision, capVer.HCIMinorRevision);
HCSPARAMS structuralParameters =
m_capabilityRegs.HCSPARAMS.ReadO;
int numberOfPorts = (int)m_structuralParameters.NumberOfPorts;
HCCPARAMS capabilityParameters =
m_capabilityRegs.HCCPARAMS.ReadO;
bool is64Bit = capabilityParameters.Bit64Addressing;
if (is64Bit) { ... }
[0035] 一旦レジスターが、基礎のメモリー領域と共に初期化されたなら、レジスターを容易に読み出し、操作し、デバイスに書き戻すことができる。
[0036] 以上で示した例では、生成されたコードは、いずれのオペレーティング・システムによっても使用することができ、特定の販売業者に限定されるのではない。加えてまたは代わりに、生成されたコードは、Ｃ＃、Ｊａｖａ、Ｃ、Ｃ＋＋等のような、任意の開発言語にすることができる。
[0037] 注記したように、ハードウェア・レジスターおよびホスト・メモリー・データー構造（ＤＡＭを介してアクセス可能）を機械読み取り可能ハードウェア仕様において記述するために、包括的ハードウェア−ソフトウェア・インターフェース言語が使用される。コード生成器は、ハードウェア−ソフトウェア・インターフェース記述に対して動作する。ハードウェア−ソフトウェア・インターフェース記述は、ハードウェア販売業者によって、提供され、有効性を確認され、維持されることが可能である。ハードウェア販売業者は、機械読み取り可能ハードウェア仕様をハードウェア設計から直接生成し、あらゆる人的誤りの潜在的可能性を排除することができる。これによって、ソフトウェア／ハードウェア・インターフェース設計および実現過程から人の介入を削減または排除し、開発時間を短縮し、均一性およびデバッギング体験の改善が得られる。
[0038] ある実施形態は、能力ベース・ドライバー・モデルに、リソースのセキュリティ強化機能(resource hardening)を実装する。具体的には、殆どのドライバー１１４は実際のハードウェアとインターフェースする。これを遂行するために、ドライバー１１４は、デバイス１０２上に存在する物理メモリー１２２の一部を、計算システム１０４の仮想アドレス空間にマッピングするか、またはＩ／Ｏ空間と呼ばれる専用アドレス空間を使用する。先に例示した技法は、ドライバー・コードがデバイス１０２にアクセスするためにマッピングされたメモリー（またはＩ／０ポート）を適正に使用することを確保するのを補助するために実装される。多くの一般的なオペレーティング・システムでは、デバイス・ドライバー１１４は、エラーまたは悪意によってでも、システム・メモリー１１２におけるいずれの物理アドレスにも自由にマッピングし使用することを試みることができる。ドライバー・ソフトウェアの特権的性質のために、オペレーティング・システムは、通例、ドライバー１１４がポート、割り込み、あるいはドライバーに属していない他のインターフェース、または特定のハードウェア・デバイス１０２を制御するためにドライバーが適正に機能するのには必要とされない他のインターフェースを割り当てないことを保証する方法を有していない。例えば、キーボード・ドライバーは、通例、ＩＲＱ１にアクセスできるはずであるが、ポート８０にアクセスする必要はない。ポート８０へのアクセスにより、極悪なキーボード・ドライバーが、ネットワークを通じて不正なウェブサイトにキーストロークを送ることを含む、キー記録機能を実装するおそれがある。これは、システムの安全性を脅かすおそれがある。
[0039] 本明細書における実施形態は、ドライバーおよびシステム・プロセスを、C#またはＪａｖａのようなマネージド・コードで実現することができる。マネージド・コードとは、サンドボックス仮想機械の管理下においてのみ実行するコンピューター・プログラム・ソース・コードである。したがって、そのように実現されたドライバーまたはシステム・プロセスはいずれも、閉じたオブジェクト空間を含む。デバイス・メモリーおよびレジスターは、初期化されるときにドライバーに提供される専用のマネージド・オブジェクトによってのみアクセスすることができる。つまり、ドライバーは、デバイスを制御するためにこのドライバーが適正に機能するのに必要とされるシステム・リソースおよびＩ／Oプロセスのみにアクセスすることができる。
[0040] これより図２を参照すると、ある実施形態が、１組２０４のＩ／Ｏリソース（メモリー・マッピングされたレジスター２０６、Ｉ／Ｏポート２０８、およびＤＭＡバッファー２１０のような）の全てが能力(capabilities)となる手法を実現する。これらの能力は、カーネル２１２によって排他的に所有され、起動時に、システムのルート・バス・ドライバー２１４に割り当てられる。システムのルート・バス・ドライバー２１４は、１組の集合２０４の全Ｉ／Ｏリソースから、部分集合２０４−１、２０４−２、．．．、２０４−ｎを、他のシステム・バス２１４−１、２１４−２、．．．、２１４−ｎに割り当てることができる。部分集合２０４−１〜２０４−ｎは、バス２１４−１〜２１４−ｎには、これらに取り付けられる特定のデバイスのために必要とするリソースだけが割り当てられるように、割り当てられる。
[0041] バス・ドライバー２１４−１〜２１４−ｎがそれらのデバイスをエミュレートするとき、１組のＩ／Ｏリソースを各チャイルドに割り当てる。例えば、バス２１４−１には、デバイス２０２−１および２０２−１が取り付けられている。バス２１４−１は、１組２０４−１−１のＩ／Ｏリソースをデバイス２０２−１に割り当てることができ、１組のリソース２０４−１−２をデバイス２０２−２に割り当てることができ、ここで組２０４−１−１および２０４−１−２は１組２０４−１の部分集合である。バスは、それに割り当てられたＩ／Ｏリソースしか割り当てることはできない。この手法は、階層的Ｉ／Ｏリソース割り当て方式を提供し、この方式は、ドライバーがそれに割り当てられたリソースだけを使用するまたは転送できることを保証するために使用することができる。これは、システムの信頼性を大幅に改善することができ、オペレーティング・システムが任意のリソースをいつでも容易に追跡し呼び出すことを可能にする。ドライバーが終了させられるときまたは終了するとき、そのリソースはそのペアレント・バス・ドライバーによって容易に取り戻すことができる。入力／出力メモリー管理ユニット（ＩＯＭＭＵ）ハードウェアによって、この方式をハードウェア・レベルで強制することができる。例えば、ドライバー開発者が、違法なメモリー・アドレスをデバイスにプログラミングしようとしても、システムの安全性を脅かすことはできない。
[0042] 図３は、典型的なバス・ドライバー３０２の構造を示す。バス・ドライバー３０２（この例では、ＰＣＩバス・ドライバー）は、ユーザー・レベル・ライブラリーとリンクされる。ユーザー・レベル・ライブラリーは、全てのドライバー・サービスを提供する（例えば、この例では、ワシントン州、RedmondのMicrosoft Corporationから入手可能なDriverFrameworkライブラリー）。また、ドライバーは、バス・ドライバー３０２がそのチャイルド・デバイスを列挙することを可能にするプラグ・アンド・プレイ・マネージャー・ライブラリー３０６ともリンクされる。列挙されるデバイス毎に、フレームワークは、バス・スロット（例えば、バス・スロット３０８−１のような）と呼ばれる、割り当てられたデバイスのリソースを保持する抽象(abstraction)を作成する。各バス・ドライバーは、例えば、バス・スロット・インターフェース３１０−１のような多数のバス・スロット・インターフェースをエクスポートし（IBusSlotインターフェースとして示される）、バス・スロット・インターフェースはランタイムによってチャイルド・ドライバー（例１１４−１によって例示される）に取り付けられる。列挙されたデバイス・ドライバーを除いて、他のサービスまたはプロセスはそれ自体をバス・スロット・インターフェースに取り付けることはできない。バス・スロット・インターフェースは、チャイルド・デバイス・ドライバーによって、その割り当てられたＩ／Ｏリソースを、デバイス例１０２−１によって例示されるデバイスに割り当てるために使用される。ドライバーは、ペアレント・ドライバーにおいてバス・スロット上で指定されたＩ／Ｏリソースだけを割り当てることができる。
[0043] このメカニズムは、Ｉ／Ｏリソース管理が、カーネルや１つのシステム・サービスの代わりに、各バス・ドライバーにおいてローカルに実行されるという意味で、容易に実現することができ、分散させることができる。
[0044] 能力として扱われるＩ／Ｏリソース以外に、実施形態は、種々のサービスの接続(connectivity)を制御することができるオペレーティング・システムを実現することができる。ドライバーはサービスとして扱われるので、実施形態は、ドライバーが使用／相互作用することができる１組のサービスを制御することができる。例えば、他のオペレーティング・システムとは異なり、ある実施形態では、ドライバーはメッセージを他のドライバーに送ることができない。何故なら、そうする能力を有さないからである（これは、メッセージをそのサービスに送るインターフェースである）。ある実施形態のオペレーティング・システムは、システムにおけるドライバーの他のコンポーネントへの接続を制限し、制御し、観察し、それについて推論することができる。能力ベースのモデルとマネージド・コードの使用の組み合わせによって、本明細書において示すような、種々の利点が得られる。
[0045] 図４を参照すると、独自のアーキテクチャーが示されている。図示する例では、ユーザー・モード４０２（例えば、ｘ８６アーキテクチャーの特権リングの内、与えられる特権が最も少ない、リング３）およびカーネル・モード４０４が示されている。マイクロカーネル４０６がカーネル・モード４０４（スーパーバイザー・モードと呼ばれることもある）に実装されてもよい。マイクロカーネル４０６は、低レベル・アドレス空間管理、スレッド管理、およびＩＰＣ通信のようなメカニズムを設ける最少量のソフトウェアである。マイクロカーネル４０６は、基本ハードウェア・テーブルを読み取る役割を担う。
[0046] ユーザー・モード４０２では、アドレス空間は、例えば、ドメイン４０８−１のようなドメインに分割される（しかし、ここでは全体的に４０８と呼ぶ）。これらのドメインは種々のプロセス（プロセス例４１０−１−１等。しかし全体的に４１０と呼ぶ）を実行し、ランタイム（ランタイム例４１２−１−１等）上に１つ以上のドライバー・プロセスを含む。実施形態は、ドライバーが、高スループットおよび低レイテンシ・デバイスをサポートすることができる、ユーザー・モード４０２のマネージド・プロセス４１０（C#またはJavaのようなマネージド・コードでドライバーをコーディングすることによってというような）である場合に実現することができる。ある実施形態では、デバイス・ドライバーを含む全てのサービスが、マネージド・コード・ライブラリーを使用して開発され、ユーザー・モード４０２で実行される。加えて、プロセス４１０およびマイクロカーネル４０６間の分離は、更に、言語の統計的に検証されたタイプ・セーフによって、行うことができる。このメカニズムは、コピーすることなく、プロセス間通信（ＩＰＣ）チャネルを通じたデーターの交換を可能にする。何故なら、全てのプロセスは１つのアドレス空間またはドメイン４０８に存在するからである。このような手法は、タイプ・セーフ言語に基づくのではない従前のシステムにおいて安全にするのは難しい。
[0047] マネージド・コードを使用して実現されたユーザー・モード・ドライバーは、システムの安全性を大幅に高め、ドライバーの開発を簡略化することができる。特に、開発者はシステムにおいて入手可能なあらゆるユーザー・モード・ライブラリーを利用することができる（ＸＭＬパーサー、キュー管理等を含む）。従前のオペレーティング・システムでは、メモリーの制約およびドライバーがそれらのアドレス空間をカーネルと共有しなければならないというようなその他の制限のために、ドライバー開発者は既存のライブラリーを全く使用することができなかった。加えて、開発者はもはやメモリー管理を心配する必要はない。プロセス・メモリーを管理する同じガベージ・コレクターがドライバーのために使用される。不適正なメモリー管理は、オペレーティング・システムの障害の最も大きな原因(sources)の１つである。ある実施形態では、システム・ドライバー・メモリーに関係するバグを排除することができる。
[0048] ある実施形態例では、１つ以上のプロセス４１０として実現されたドライバーは、シングル・スレッド(single threaded)である。つまり、開発者は、同期、スレッド、および割り込みレベルについて心配する必要はない。ドライバーの複雑さの多くは解消され、開発者はドライバーの機能性に注力する。
[0049] ドライバーには、標準的なタイプ−セーフ・インターフェースを介してアクセスすることができる。一般のオペレーティング・システムは、ドライバーへのアクセスを、Open, Close, Read, Writeのような数個の予め定められた機能およびDeviceloControl（'ioctl'として知られる）のような汎用インターフェースに限定する。以前のシステムでは、ドライバーは数個の周知のハードウェア・コンポーネントを制御し、これらが実行するタスクは制限されていたが、これは、少なくとも一部のハードウェア・デバイス（例えば、グラフィクス・アクセレレータのようなハードウェア・アクセレレータ）が広範で複雑なインターフェースをそれらのホストに露出する、最近のシステムにとっては非効率的である。ある実施形態において提供される解決手段では、オペレーティング・システムはドライバーをファースト・クラス・シチズン(first class-citizen)として扱う。
[0050] プロセス４１０として実現されたドライバーは、任意の他のシステム・サービスのような、タイプ・フェース・インターフェースを介してアクセスされる。このような実施態様は、言語のタイプ・セーフ機構を利用し、コンパイル時に誤ったメソッドの呼び出しを捕らえる。コンパイル時−型チェックを行うために、コンパイラは、コードにおける変数または式についてのデーター型情報を知る必要がある。インターフェースは、インターフェース・コンシューマーとインターフェース実施態様との間に契約を設ける。メソッドのシグネチャーは、コンパイルの間に統計的にチェックすることができる。異なる型のパラメータの不一致は、実行中のシステム(running system)では事実上起こり得ない。加えて、これらのエラーは、コンパイル時にアプリケーション開発者によって捕らえられ、カーネル・モード４０４においてドライバー開発者によるランタイム・チェックを必要としない。
[0051] 安全性および開発の容易さの他に、実施形態は、デバイス・ドライバーが、共通のカーネル・モード・デバイス・ドライバーに比肩する高いスループットおよび低いレイテンシを達成することを可能にする。これは、ゼロ−コピーＩ／Ｏパスを実施する能力によって達成することができる。「ゼロ−コピー」とは、システムに入力したデーターはメモリーに１回だけ書き込まれ、次いで、オペレーティング・システム内部およびアプリケーション・コード内部の双方において、データーをコピーする必要なく、多くの抽象レイヤによって直接使用することができるという事実を指す。ゼロ−コピーＩ／Ｏパスは、ＣＰＵが１つのメモリー位置から他のメモリー位置へのコピーを実行しないものである。むしろ、ＣＰＵは他のタスクを実行することができる。これは、コピーを行うために、ユーザー・モード４０２とカーネル・モード４０４との間でシステムに切り替えさせるためのコンテキスト切り替えをせずに済ませることができる。これより、以下に、ゼロ−コピーＩ／Ｏパスを使用して、マネージド・ユーザー・モード・デバイス・ドライバーがこのような成果を達成することを可能にする技法を例示する。
[0052] 実施形態は、効率的な割り込みディスパッチを実行するように構成することができる。効率的にハードウェア割り込みをユーザー・モード・デバイスに送り出す能力は新規である。割り込みのディスパッチングは、オペレーティング・システムのマイクロカーネル、ドメイン・カーネル、およびドライバーのフレームワーク・ライブラリー間における緊密な相互作用によって実行される。
[0053] 割り込みをディスパッチするメカニズムは、Ｉ／Ｏ割り込みマネージャー、ドライバー・フレームワーク・ライブラリー、および効率的なマイクロカーネル割り込み処理を含む３層アーキテクチャーを使用する。
[0054] 図４に示すように、各ドメイン４０８はドメイン・カーネルを含む。その一例が４１４−１に例示されている（しかし、ここでは全体的に４１４と呼ぶ）。Ｉ／Ｏ割り込みマネージャーは、その一例が４１６−１に例示されているが（しかし、ここでは全体的に４１６と呼ぶ）、ドメイン・カーネル４１４の一部であり、ハードウェア・デバイス１０２とデバイス・ドライバー・プロセス４１０との間の橋渡しをする。これは、デバイス・ドライバーのＩＲＱ４１８上の登録を管理し、ドライバー・プロセス４１０に割り込みをディスパッチし、ＩＲＱが多数のデバイスによって共有されるときに割り込みの共有を処理する役割を担う。全てのデバイス・ドライバーがプロセスにおいて実行すると、実施形態は、デバイス・ドライバーがカーネルにおいて実行する従前のモノリシックＯＳカーネル設計よりも強い分離および障害封じ込めをドライバーに対して強制することができる。
[0055] ドライバー・フレームワーク・ライブラリーは、通知を受けるために、割り込みハンドラをドメイン・カーネル４１４に登録する役割を担う。ハードウェア割り込みがドメイン・カーネル４１４において受け取られると、割り込みハンドラがトリガーされ、予め登録されているドライバー・ルーチンが呼び出される。ユーザー・モード４０２からカーネル・モード４０４へのコンテキスト切り替えを伴わないので、メソッドを呼び出すオーバーヘッドは非常に低い。
[0056] 実施形態は、効率的なマイクロカーネル割り込み処理を実現する。ある実施形態では、マイクロカーネル４０６は割り込み可能であるが、優先使用可能ではない。論理プロセッサーは、マイクロカーネル４０６のコンテキストで実行している間、割り込みを受けることができるが、そのコンテキストを止めることも切り替えることもできない。割り込みディスパッチ・レイテンシを最小限に抑えるために、実施形態は、プロセッサーがマイクロカーネル４０６内部で費やすことができる時間量を制限する。ある実施形態は、システム・コールに対して連続実行方式を実施するが、潜在的に、予め設定された限度よりも長い時間がかかる可能性がある。限度および連続方式は、マイクロカーネル４０６が割り込みをドメイン・カーネル４１４に、非常に低いレイテンシで、送り出すのを可能にする。全てのハードウェア割り込み（ＭＳＩ、ＩＲＱ、および仮想）は、ドライバーの一部であるユーザー・モード・ライブラリーに送り出される。割り込みディスパッチ・レイテンシを最小限に抑えることは、ある実施形態では、ゼロ−コピーＩ／Ｏパスを使用することによって達成することができる。
[0057] ゼロ−コピーＩ／Ｏパスの例示的な一例を、これより示す。再度図１を参照すると、システム・メモリー１１２が示されている。プロセス４１０は、システム・メモリー１１２の一部を割り当てることができる。マイクロカーネル４０６（図４参照）は、プロセス４１０にメモリーを割り当てさせることができるが、一旦メモリーがプロセス４１０に割り当てられると、プロセス４１０はシステム・メモリーのその部分を制御する。ハードウェア・ドライバーの例では、ハードウェア・デバイス１０２がメモリーのこの部分に書き込むことができる。ドライバー・プロセス４１０は、次いで、このメモリーの部分にインミュータブルであることの印を付ける。インミュータブルであるメモリーとは、そのコンテンツおよび／またはアドレスを変化させることができないメモリーである。このメモリーの部分がインミュータブルになるので、このメモリーの部分にアクセスすることに対して実際の制約はなくなる。つまり、システムは、異なるプロセスがメモリーから読み取ることを許可するために、カーネル・モードに切り替える必要はない。このため、ドライバー・プロセス４１０は、コンテキストの切り替えを必要とせずに、このメモリーの部分にアクセスすることができ、したがってハードウェア・デバイス１０２からデーターを得ることができる。ハードウェア・デバイス１０２は、ドライバーがユーザー・モードで実装されるときでも高い効率および低いレイテンシを達成できるように、素早くそして効率的にこのメモリーの部分に書き込む。
[0058] メモリーのインミュータブルな部分の異なるビューを提供することによって、しかるべき方法でデーターを異なるプロセス４１０に送り出すことができる。つまり、特定のプロセス４１０に必要とされるデーターの部分をコピーするのではなく、メモリーのインミュータブルな部分へのポインタを使用することができ、メモリーのインミュータブルな部分におけるデーターの論理ビューが、該当するデーターを提供することができる。したがって、特定のプロセス４１０の観点からは、データーがコピーされて該当するフォーマットで供給されるように見えるが、実際には、データー・コピーは行われない。
[0059] 同様の機能性は、ドライバー・プロセス４１０がデーターをハードウェア・デバイス１０２に送るためにも使用することができる。具体的には、ドライバー・プロセス４１０がデーターをシステム・メモリー１１２の一部に書き込むことができる。この一部には、同じドライバー・プロセス４１０または他のドライバー・プロセスによって、インミュータブルであるという印を付けることができる。次いで、システムがカーネル・モード４０４に切り替える必要なく、ハードウェア・デバイス１０２によってメモリーを読み取ることができる。
[0060] ある実施形態では、メモリーのインミュータブルな部分には、カウンターを関連付けることができる。プロセスがメモリーのインミュータブルな部分にアクセスする毎に、カウンターは増加する。このプロセスが実行されメモリーのインミュータブルな部分を読み出すと、カウンターは減少する。こうして、メモリーのインミュータブルな部分を読み出した全てのプロセスが、メモリーのインミュータブルな部分の使用を終了した後、カウンターはゼロに減少し、このメモリーの部分を、他のメモリー動作のために解放することができる。
[0061] デバイス制御のためのＤＭＡチャネルの使用に関係する別の技法がある。チャネルは、チャネル・エンドポイントと呼ばれる正確に２つのエンドポイントを有する双方向メッセージ・コンジット(bi-directional message conduit)である。ＤＭＡチャネルは、大量のパケット化データーをＤＭＡを介して交換するアプリケーションとデバイス・ドライバーとの間のギャップを橋渡しする高性能メカニズムである。これは、標準的なプロセス間通信（ＩＰＣ）チャネルの特殊化であり、主に、読み取り可能なＤＭＡ動作、およびチャネルにおけるメッセージの非同期回収(asynchronous retirement)を提供することが異なる。ＩＰＣメッセージは、２つの部分、即ち、１つの必須部分および他の任意部分を有する。必須部分は、チャネルのスロットにコピーされたインライン・データーであり、任意部分は、チャネルにわたって転送される（または共有される）ハンドルを含む。ＤＭＡチャネルは、以下の面で一意である。
・これらは全体的にユーザー・モードで実行される（ドライバーおよびプロセスが生きている場合）。
・これらは、背圧(back pressure)を与える。アプリケーションとネットワーク・ドライバーとの間で渡されるメッセージ毎にメモリー割り当てはない。更に、データーは、完全に消費されるまで、チャネル内に留まることができ、このデーターの背後にあるメッセージは処理し続けることができる。
・これらはゼロ−コピー・サポートを含む。ＤＭＡはリング・バッファーから実行することができる。
・これらは、任意の制御メッセージに対するサポートを含む。これは、ソフトウェア・セグメント化オフロードのような最適化を可能にする。
[0062] 以下の論述は、実行することができる多数の方法および方法のアクトについて述べる。方法のアクトはある順序で論ぜられるか、または特定の順序で現れるようにフロー・チャートに示されるが、具体的に述べられないか要求されない限り、特定の順序である必要はない。何故なら、アクトは、そのアクトが実行される前に完了する他のアクトに依存するからである。
[0063] これより図５を参照すると、方法５００が示されている。方法５００は、計算環境において実施することができる。方法５００は、ハードウェアとインターフェースするためのデバイス・ドライバーと共に使用されるコードを自動的に生成するアクトを含む。方法５００は、ハードウェア・デバイスの機械読み取り可能記述を受けるアクトを含む（アクト５０２）。機械読み取り可能記述は、ハードウェア・デバイスのハードウェア・レジスターまたは供給メモリー構造の内少なくとも１つを含む。例えば、図１は、ハードウェア・デバイス１０２の機械読み取り可能記述１１６の例を示す。
[0064] 方法５００は、更に、ハードウェア・デバイスが一緒に使用されることになるオペレーティング・システムを決定するアクトを含む（アクト５０４）。例えば、コード生成ツール１１８は、ハードウェア・インターフェース・レイヤ１１５が作成されているオペレーティング・システムを設定する情報にアクセスすることができるか、またはその情報を有してもよい。
[0065] 更に、方法５００は、コード生成ツール上で機械読み取り可能記述を処理して、決定されたオペレーティング・システムに特定的なハードウェア・デバイス用に、ハードウェア・ドライバーのコードを自動的に生成するアクトも含む（アクト５０６）。例えば、図１は、コード生成ツール１１８が機械読み取り可能ハードウェア仕様(specification)１１６を実行することを示す。
[0066] 種々のドライバー・コード部分を生成することができる。例えば、方法５００のある実施形態を実施すると、ハードウェア・ドライバーのコードを生成するアクトは、レジスターに対して読み取りおよび書き込みを行い、レジスターのフィールドを解釈するハードウェア・アクセス・メソッド(hardware access method)を生成するアクトを含むことができる。代わりにまたは加えて、方法５００の実施形態を実施すると、ハードウェア・ドライバーのコードを生成するアクトは、共有構造フィールドに対して読み取りおよび書き込みを行うメソッドを生成するアクトを含むことができる。代わりにまたは加えて、方法５００の実施形態を実施すると、ハードウェア・ドライバーのコードを生成するアクトは、ハードウェア・デバイスの機械読み取り可能記述において表現されるハードウェア・インターフェース・エンティティのためのメモリー・アロケーターを生成するアクトを含むことができる。代わりにまたは加えて、方法５００の実施形態を実施すると、ハードウェア・ドライバーのコードを生成するアクトは、ハードウェア・インターフェース・エンティティを解釈し追跡するログ・モジュールを生成するアクトを含むことができる。代わりにまたは加えて、方法５００の実施形態を実施すると、デバッガー拡張がハードウェア・インターフェース・エンティティを可視化することができる。
[0067] 方法５００のある実施形態を実施すると、ハードウェア・デバイスの機械読み取り可能記述をハードウェア販売業者によって提供ことができる。
[0068] 方法５００のある実施形態を実施すると、ハードウェア・ドライバーのために生成されるコードを、マネージド・コードとして生成することができる。
[0069] これより図６を参照すると、方法６００が示されている。方法６００は、計算環境において実施することができる。方法６００は、ハードウェア・ドライバーに制限を強制するアクトを含む。方法６００は、システム・カーネルから、Ｉ／Ｏリソースをシステムのルート・バスに割り当てるアクトを含む（アクト６０２）。例えば、図２は、リソースをバス・ドライバー２１４に割り当てることによって、Ｉ／Ｏリソースがシステムのルート・バスに割り当てられることを示す。
[0070] ルート・バスから、方法６００は、Ｉ／Ｏリソースの部分集合をデバイス・バスに割り当てるアクトを含む（アクト６０４）。Ｉ／Ｏリソースの部分集合をデバイス・バスに割り当てるアクトは、ルート・バスによってそれに割り当てられたＩ／Ｏリソースを割り当てることだけが可能になるように、デバイス・バスを制限するアクトを含む。例えば、図２において、デバイス・バス２１４−１〜２１４−ｎは、それらに割り当てられたリソースを有する。これらのデバイス・バスの各々は、それらに割り当てられたリソースを更に割り当てることだけができる。
[0071] 方法６００は、更に、デバイス・バスからデバイスにＩ／Ｏリソースを、デバイス・インターフェースを介して、割り当てるアクトを含む（アクト６０６）。
[0072] 方法６００のある実施形態が実現されると、ルート・バスによってそれに割り当てられたＩ／Ｏリソースを割り当てることだけが可能になるようにデバイス・バスを制限するアクトは、バス・ドライバーをマネージド・コードで実装することによって遂行することができる。
[0073] 方法６００が実施されると、Ｉ／Ｏリソースの部分集合をデバイス・バスに割り当てるアクトは、マネージド・コードで実装されたバス・ドライバーを呼び出すアクトを含むことができる。
[0074] 方法６００が実施されると、Ｉ／Ｏリソースをデバイスに割り当てるアクトは、マネージド・コードで実装されたデバイス・ドライバーを呼び出すアクトを含むことができる。
[0075] 更に、方法６００は、他のサービスおよびプロセスが、それら自体をデバイス・インターフェースに取り付けることを禁止するアクトも含むことができる。
[0076] これより図７を参照すると、方法７００が示されている。方法７００は、計算環境において実施することができる。方法７００は、高スループットおよび低レイテンシ・デバイスをサポートすることができるタイプ・セーフ・ドライバーを実装するアクトを含む。方法７００は、ハードウェア・デバイスからデーターを受けるアクトを含む（アクト７０２）。更に、方法７００は、ゼロ−コピーを使用してユーザー・モードで実行する１つ以上のドライバー・プロセスにデーターを送り出し、１つ以上のドライバー・プロセスが、高スループットおよび低レイテンシ・ハードウェア・デバイスをサポートすることを可能にするアクトも含む（アクト７０４）。
[0077] 方法７００を実施すると、データーを送り出すアクトを、カーネル・モードを先取することなく、実行することができる。代わりにまたは加えて、方法７００は、更に、プロセッサーがカーネル・モードにおいて費やす時間量を制限するアクトを含むこともできる。代わりにまたは加えて、方法７００を実施すると、ドライバー・プロセスをマネージド・コードで実装することができる。代わりにまたは加えて、方法７００は、更に、ユーザー・モードで実装されたＩ／Ｏ割り込みマネージャーが、ユーザー・モード・デバイス・ドライバーを割り込み時に登録するアクトを含むこともできる。ある実施形態では、Ｉ／Ｏ割り込みマネージャーは、割り込みをドライバー・プロセスにディスパッチする。代わりにまたは加えて、方法７００は、更に、ドライバーをシングル・スレッド・プロセスとして実装するアクトも含むことができる。代わりにまたは加えて、方法７００を実施すると、どのユーザー・モード・ライブラリーが１つ以上のドライバー・プロセスを実装するために使用できるかに対する制限なく、１つ以上のドライバー・プロセスを実装することができる。
[0078] 更に、以上の方法は、１つ以上のプロセッサーと、コンピューター・メモリーのようなコンピューター読み取り可能媒体とを含むコンピューター・システムによって実施することができる。具体的には、コンピューター・メモリーは、コンピューター実行可能命令を格納することができ、コンピューター実行可能命令が１つ以上のプロセッサーによって実行されると、以上の実施形態において説明したアクトのような、種々の機能を実行させる。
[0079] 本発明の実施形態は、以下で更に詳しく説明するような、コンピューター・ハードウェアを含む特殊目的または汎用コンピューターを含む、または利用することができる。また、本発明の範囲に該当する実施形態は、コンピューター実行可能命令および／またはデーター構造を搬送または格納するために、物理的コンピューター読み取り可能媒体および他のコンピューター読み取り可能媒体も含む。このようなコンピューター読み取り可能媒体は、汎用または特殊目的コンピューター・システムによってアクセスすることができる、任意の入手可能な媒体とすることができる。コンピューター実行可能命令を格納するコンピューター読み取り可能媒体は、物理的記憶媒体である。コンピューター実行可能命令を搬送するコンピューター読み取り可能媒体は、送信媒体である。つまり、一例として、そして限定ではなく、本発明の実施形態は、少なくとも２つの全く異なる種類のコンピューター読み取り可能媒体、即ち、物理的コンピューター読み取り可能記憶媒体、および送信コンピューター読み取り可能媒体を含むことができる。
[0080] 物理的コンピューター読み取り可能記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク・ストレージ（ＣＤ、ＤＶＤ等のような）、磁気記憶デバイスまたは他の磁気記憶デバイス、あるいはコンピューター実行可能命令またはデーター構造の形態で所望のプログラム・コード手段を格納するために使用することができ、汎用または特殊目的コンピューターによってアクセスすることができる任意の他の媒体を含む。
[0081] 「ネットワーク」とは、コンピューター・システムおよび／またはモジュールおよび／または他の電子デバイス間において電子データーの移送を可能にする１つ以上のデーター・リンクと定められる。ネットワークまたは他の通信接続（ハードワイヤ、ワイヤレス、あるいはハードワイヤまたはワイヤレスの組み合わせ）を介して情報がコンピューターに転送または供給されるとき、このコンピューターがこの接続を送信媒体と見なすのは当然のことである。送信媒体は、所望のプログラム・コード手段をコンピューター実行可能命令またはデーター構造の形態で搬送するために使用することができ、汎用または特殊目的コンピューターによってアクセスすることができるネットワークおよび／またはデーター・リンクを含むことができる。以上のものの組み合わせも、コンピューター読み取り可能媒体の範囲内に含まれる。
[0082] 更に、種々のコンピューター・システム・コンポーネントに到達したとき、コンピューター実行可能命令またはデーター構造の形態であるプログラム・コード手段を自動的に送信コンピューター読み取り可能媒体から物理的コンピューター読み取り可能記憶媒体に（またはその逆）に転送することができる。例えば、ネットワークまたはデーター・リンクを介して受信されたコンピューター実行可能命令またはデーター構造は、ネットワーク・インターフェース・モジュール（例えば、「ＮＩＣ」）内にあるＲＡＭにバッファーすることができ、次いで最終的にコンピューター・システムのＲＡＭおよび／またはコンピューター・システムにおける、もっと揮発性が少ないコンピューター読み取り可能物理記憶媒体に転送することができる。このように、コンピューター読み取り可能物理的記憶媒体は、送信媒体も利用する（または主に利用する場合であっても）コンピューター・システム・コンポーネントに含むことができる。
[0083] コンピューター実行可能命令は、例えば、命令およびデーターを含み、汎用コンピューター、特殊目的コンピューター、または特殊目的処理デバイスに、一定の機能または機能の一群を実行させる。コンピューター実行可能命令は、例えば、バイナリー、アセンブリー言語のような中間フォーマット命令、またはソース・コードであってもよい。主題について、構造的特徴および／または方法論的アクトに特定的な文言で説明したが、添付する特許請求の範囲において定められる主題はかならずしも説明した特徴や以上で説明したアクトには限定されないことは理解されてしかるべきである。逆に、説明した特徴およびアクトは、特許請求の範囲を実現する形態例として開示されたまでである。
[0084] 当業者は、多くのタイプのコンピューター・システム構成を有するネットワーク計算環境において本発明が実施されてもよいことを認めよう。多くのタイプのコンピューター・システム構成には、パーソナル・コンピューター、デスクトップ・コンピューター、ラップトップ・コンピューター、メッセージ・プロセッサー、ハンドヘルド・デバイス、マルチプロセッサー・システム、マイクロプロセッサー・ベースまたはプログラマブル消費者用電子機器、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター、移動体電話機、ＰＤＡ、ページャー、ルーター、スイッチ等が含まれる。本発明は、分散型システム環境において実施することもでき、ローカルおよびリモート・コンピューター・システムは、ネットワークを介してリンクされ（ハードワイヤ結合データー・リンク、ワイヤレス・データー・リンク、またはハードワイヤ結合およびワイヤレス・データー・リンクの組み合わせのいずれかによって）、双方共タスクを実行する。分散型システム環境では、プログラム・モジュールはローカルおよびリモート双方のメモリー記憶デバイスに配置されてもよい。
[0085] 本発明は、その主旨や本質的な特性から逸脱することなく、他の具体的な形態で具体化することもできる。以上で説明した実施形態は、いかなる観点においても、限定ではなく例示として見なされてしかるべきである。したがって、本発明の範囲は、以上の説明ではなく、添付する特許請求の範囲によって示されるものとする。特許請求の範囲の意味および均等の範囲に該当する全ての変更は、その範囲内に含まれるものとする。

Claims (8)

  1. 計算環境において、ハードウェアとインターフェースするためにデバイス・ドライバーと共に使用されるコードを自動的に生成する方法であって、
    ハードウェア・デバイスの機械読み取り可能記述を受けるアクトであって、機械読み取り可能記述前記が、前記ハードウェア・デバイスのハードウェア・レジスターまたは共有メモリー構造の内少なくとも１つを含む、アクトと、
    前記ハードウェア・デバイスと共に使用されるオペレーティング・システムを決定するアクトと、
    前記決定したオペレーティング・システムに特定的な前記ハードウェア・デバイスのために、ハードウェア・ドライバー用コードを自動的に生成するために、コード生成ツール上で前記機械読み取り可能記述を処理するアクトと、
    を含む、方法。
  2. 請求項１記載の方法において、ハードウェア・ドライバーのコードを生成するアクトが、レジスターに対して読み取りおよび書き込みを行い、前記レジスターのフィールドを解釈するためのハードウェア・アクセス・メソッドを生成するアクトを含む、方法。
  3. 請求項１記載の方法において、ハードウェア・ドライバーのコードを生成するアクトが、共有構造フィールドに対して読み取りおよび書き込みを行うためのメソッドを生成するアクトを含む、方法。
  4. 請求項１記載の方法において、ハードウェア・ドライバーのコードを生成するアクトが、前記ハードウェア・デバイスの前記機械読み取り可能記述において表現されたハードウェア・インターフェース・エンティティに対して、メモリー・アロケーターを生成するステップを含む、方法。
  5. 請求項１記載の方法において、ハードウェア・ドライバーのコードを生成するアクトが、ハードウェア・インターフェース・エンティティを解釈し追跡するログ・モジュールを生成するアクトを含む、方法。
  6. 請求項１記載の方法において、ハードウェア・ドライバーのコードを生成するアクトが、ハードウェア・インターフェース・エンティティを可視化するデバッガー拡張を生成するアクトを含む、方法。
  7. 請求項１記載の方法において、ハードウェア・デバイスの前記機械読み取り可能記述が、ハードウェア販売業者によって提供される、方法。
  8. 請求項１記載の方法において、前記生成されたハードウェア・ドライバーのコードが、マネージド・コードとして生成される、方法。
JP2015551765A 2013-01-04 2014-01-03 ハードウェア・デバイス用ソフトウェア・インターフェース Withdrawn JP2016509714A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/734,712 US9811319B2 (en) 2013-01-04 2013-01-04 Software interface for a hardware device
US13/734,712 2013-01-04
PCT/US2014/010113 WO2014107540A1 (en) 2013-01-04 2014-01-03 Software interface for a hardware device

Publications (2)

Publication Number Publication Date
JP2016509714A true JP2016509714A (ja) 2016-03-31
JP2016509714A5 JP2016509714A5 (ja) 2017-03-16

Family

ID=50097813

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015551765A Withdrawn JP2016509714A (ja) 2013-01-04 2014-01-03 ハードウェア・デバイス用ソフトウェア・インターフェース

Country Status (6)

Country Link
US (1) US9811319B2 (ja)
EP (1) EP2941696A1 (ja)
JP (1) JP2016509714A (ja)
KR (1) KR102104695B1 (ja)
CN (1) CN105051682B (ja)
WO (1) WO2014107540A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8176468B2 (en) * 2005-12-01 2012-05-08 Cypress Semiconductor Corporation Multivariable transfer functions
US9740597B2 (en) * 2015-03-09 2017-08-22 Oracle International Corporation Transactional execution of native methods
US10430361B1 (en) 2015-12-17 2019-10-01 Cru Acquisition Group, Llc Combination write blocker
CN109213670A (zh) * 2017-06-30 2019-01-15 中兴通讯股份有限公司 实现白盒otn硬件设备的方法及装置、存储介质
US10587287B2 (en) 2018-03-28 2020-03-10 International Business Machines Corporation Computer system supporting multiple encodings with static data support
US10720941B2 (en) 2018-04-09 2020-07-21 International Business Machines Corporation Computer system supporting migration between hardware accelerators through software interfaces
US10587284B2 (en) 2018-04-09 2020-03-10 International Business Machines Corporation Multi-mode compression acceleration
US10374629B1 (en) 2018-05-07 2019-08-06 International Business Machines Corporation Compression hardware including active compression parameters
US11169783B2 (en) * 2019-02-05 2021-11-09 Vayavya Labs Private Limited System and method for generating an executable hardware-software interface specification
US11461490B1 (en) 2020-09-23 2022-10-04 Cru Data Security Group, Llc Systems, methods, and devices for conditionally allowing processes to alter data on a storage device

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08161250A (ja) * 1994-12-06 1996-06-21 Canon Inc 情報処理装置
US6009476A (en) * 1995-11-21 1999-12-28 Diamond Multimedia Systems, Inc. Device driver architecture supporting emulation environment
US6148346A (en) * 1996-06-20 2000-11-14 Peerless Systems Imaging Products, Inc. Dynamic device driver
US6275857B1 (en) 1996-10-30 2001-08-14 Microsoft Corporation System and method for freeing shared resources in a computer system
US6202146B1 (en) 1998-06-29 2001-03-13 Sun Microsystems, Inc. Endianness checking for platform-independent device drivers
WO2001044935A1 (en) * 1999-12-15 2001-06-21 Sun Microsystems, Inc. Computer system with an improved device and driver framework
US7089562B1 (en) * 2000-05-04 2006-08-08 International Business Machines Corporation Universal driver server
US6907474B2 (en) 2000-09-15 2005-06-14 Microsoft Corporation System and method for adding hardware registers to a power management and configuration system
US7234144B2 (en) 2002-01-04 2007-06-19 Microsoft Corporation Methods and system for managing computational resources of a coprocessor in a computing system
US8225306B2 (en) 2002-12-12 2012-07-17 Dell Products L.P. Platform independent imaging method and system
US7536486B2 (en) * 2004-07-30 2009-05-19 Microsoft Corporation Automatic protocol determination for portable devices supporting multiple protocols
US20060034167A1 (en) 2004-07-30 2006-02-16 International Business Machines Corporation Communication resource reservation system for improved messaging performance
US7613813B2 (en) 2004-09-10 2009-11-03 Cavium Networks, Inc. Method and apparatus for reducing host overhead in a socket server implementation
JP4863450B2 (ja) * 2005-03-29 2012-01-25 キヤノン株式会社 デバイスドライバプログラムをカスタマイズするための情報処理装置及びデバイスドライバプログラムのカスタマイズ方法
US7949766B2 (en) 2005-06-22 2011-05-24 Cisco Technology, Inc. Offload stack for network, block and file input and output
US8713180B2 (en) 2005-06-22 2014-04-29 Cisco Technology, Inc. Zero-copy network and file offload for web and application servers
US8074231B2 (en) * 2005-10-26 2011-12-06 Microsoft Corporation Configuration of isolated extensions and device drivers
CN101297277B (zh) 2005-10-26 2012-07-04 微软公司 静态可验证进程间通信隔离进程
CN1928816A (zh) 2006-09-26 2007-03-14 武汉大学 嵌入式系统软件的模型驱动与构件化开发方法
US7617377B2 (en) 2006-10-17 2009-11-10 International Business Machines Corporation Splitting endpoint address translation cache management responsibilities between a device driver and device driver services
GB2443277B (en) 2006-10-24 2011-05-18 Advanced Risc Mach Ltd Performing diagnostics operations upon an asymmetric multiprocessor apparatus
US7904878B2 (en) * 2006-12-26 2011-03-08 Vayavya Technologies Private Limited Simplifying generation of device drivers for different user systems to facilitate communication with a hardware device
JP2009031985A (ja) * 2007-07-26 2009-02-12 Denso Corp ソフトウェア生成装置、および、ソフトウェア生成装置に用いるプログラム
US8589866B2 (en) * 2007-08-29 2013-11-19 Ricoh Company, Ltd. Automatically generating capability-based computer peripheral device drivers
US20090064196A1 (en) * 2007-08-31 2009-03-05 Microsoft Corporation Model based device driver code generation
US8185783B2 (en) 2007-11-22 2012-05-22 Microsoft Corporation Split user-mode/kernel-mode device driver architecture
US20090190150A1 (en) * 2008-01-24 2009-07-30 Selvaraj Senthil K On-Demand Print Driver
US8024417B2 (en) 2008-06-04 2011-09-20 Microsoft Corporation Simple flow control protocol over RDMA
US8769036B2 (en) 2009-10-30 2014-07-01 International Business Machines Corporation Direct sending and asynchronous transmission for RDMA software implementations
US8200853B2 (en) * 2010-01-14 2012-06-12 Microsoft Corporation Extensions for USB driver interface functions
US20120092719A1 (en) * 2010-10-18 2012-04-19 Aventura Hq, Inc. Centralized print job routing in a distributed printing environment
US8806511B2 (en) 2010-11-18 2014-08-12 International Business Machines Corporation Executing a kernel device driver as a user space process
US8683428B2 (en) 2011-03-23 2014-03-25 Microsoft Corporation Automated generation of client/driver communication interfaces

Also Published As

Publication number Publication date
KR20150104592A (ko) 2015-09-15
US20140196004A1 (en) 2014-07-10
CN105051682A (zh) 2015-11-11
EP2941696A1 (en) 2015-11-11
CN105051682B (zh) 2018-02-23
KR102104695B1 (ko) 2020-04-24
US9811319B2 (en) 2017-11-07
WO2014107540A1 (en) 2014-07-10

Similar Documents

Publication Publication Date Title
KR102104695B1 (ko) 하드웨어 디바이스에 대한 소프트웨어 인터페이스
US9823851B2 (en) Secure migratable architecture having security features
Chen et al. Enabling FPGAs in the cloud
US10862982B2 (en) Cloud-scale heterogeneous datacenter management infrastructure
JP5122597B2 (ja) 仮想プロセッサへの直接的なインタラプトの送信
US10977018B1 (en) Development environment for heterogeneous devices
EP2941694B1 (en) Capability based device driver framework
TW201923568A (zh) 實現驅動的系統及方法
EP2941695B1 (en) High throughput low latency user mode drivers implemented in managed code
JP2016186697A (ja) 関数間変数共有方法及び機構
Kristiansen PCIe Device Lending
McKitterick Development of benos: an x86 operating system
Crutcher et al. Operating System
Caforio VOSySmonitoRV: a mixed-criticality solution on 64bit Linux-capable RISC-V platform
Silva Xvisor Deployment Under Zynq-7000
Verhulst et al. Requirements and Specifications for the OpenComRTOS Project
Danish Terrier: an embedded operating system using advanced types for safety
Krithika et al. Virtualization of the Legacy VxWorks Application onto the Linux Platform
Fan et al. Advanced Memory Checking for MPI Parallel Applications Using MemPin

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170104

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170207

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20180309