KR102104695B1 - 하드웨어 디바이스에 대한 소프트웨어 인터페이스 - Google Patents

하드웨어 디바이스에 대한 소프트웨어 인터페이스 Download PDF

Info

Publication number
KR102104695B1
KR102104695B1 KR1020157021046A KR20157021046A KR102104695B1 KR 102104695 B1 KR102104695 B1 KR 102104695B1 KR 1020157021046 A KR1020157021046 A KR 1020157021046A KR 20157021046 A KR20157021046 A KR 20157021046A KR 102104695 B1 KR102104695 B1 KR 102104695B1
Authority
KR
South Korea
Prior art keywords
hardware
driver
code
operating system
interface
Prior art date
Application number
KR1020157021046A
Other languages
English (en)
Other versions
KR20150104592A (ko
Inventor
야론 와인스버그
진송 유
맥심 그라바니크
데이비드 마사렌티
Original Assignee
마이크로소프트 테크놀로지 라이센싱, 엘엘씨
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 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 filed Critical 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Publication of KR20150104592A publication Critical patent/KR20150104592A/ko
Application granted granted Critical
Publication of KR102104695B1 publication Critical patent/KR102104695B1/ko

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

하드웨어와 인터페이스하기 위해 디바이스 드라이버들에서 사용되는 코드를 자동으로 생성하는 것. 이 방법은 하드웨어 디바이스의 하드웨어 레지스터들 또는 공유 메모리 구조들 중 적어도 하나를 포함한 하드웨어 디바이스의 기계 판독가능 설명(machine readable description)을 수신하는 단계를 포함한다. 이 방법은 하드웨어 디바이스가 사용될 운영 체제를 결정하는 단계를 추가로 포함한다. 이 방법은 결정된 운영 체제에 특유한 하드웨어 디바이스의 하드웨어 드라이버를 위한 코드를 자동으로 생성하기 위해 코드 생성 도구에서 기계 판독가능 설명을 처리하는 단계를 추가로 포함한다.

Description

하드웨어 디바이스에 대한 소프트웨어 인터페이스{SOFTWARE INTERFACE FOR A HARDWARE DEVICE}
하드웨어 디바이스에 대한 소프트웨어 인터페이스에 관한 것이다.
컴퓨터 및 컴퓨팅 시스템은 현대 생활의 거의 모든 측면에 영향을 미쳤다. 컴퓨터는 일반적으로 업무, 오락, 건강 관리, 운송, 엔터테인먼트, 가사 관리 등에 관여되어 있다.
범용 컴퓨팅 시스템은 디바이스 드라이버라고 알려진 코드를 사용하여 다수의 디바이스들을 이용할 수 있다. 디바이스 드라이버는 하드웨어 또는 기타 디바이스를 CPU 레지스터, 시스템 메모리 레지스터 등과 같은 시스템 자원과 인터페이스하게 하는 방법으로서 기능한다. 디바이스 드라이버는 전형적으로 특권 모드(privileged mode)인 커널 모드(kernel mode)에서 실행된다. 상세하게는, 커널 모드에서, 드라이버 코드는 임의의 메모리 주소에 액세스하고 임의의 시스템 레벨 구성요소를 제어할 수 있다. 따라서, 결함있는 또는 악의적인 드라이버는 컴퓨팅 시스템의 무결성을 쉽게 손상시켜, 크래시(crash) 또는 데이터 손상(data corruption)을 가져올 수 있다.
이와 같이, 디바이스 드라이버는 안전하지 않다. 객체 지향 설계 방법, 언어 타입 안정성(language type-safety), 및 정적 코드 검증(static code verification)이 진보된 플랫폼(예컨대, 소위 클라우드) 및 개발 환경에 들어가게 되지만, 디바이스 드라이버는 여전히 안전하지 않은 언어(예컨대, C/C++)를 사용하여 개발되고, 형식 없는(type-less), 비객체 지향의(non-object-oriented) 그리고 오류를 발생시킬 수 있는 인터페이스를 사용하여 액세스된다. 대부분의 디바이스 드라이버는 여전히 커널 모드에서 실행되어, 단일의 소프트웨어 버그가 시스템 오류(system failure)를 야기할 가능성을 증가시킨다. 게다가, 임의의 드라이버가 사용자 모드에서 구현되는 한, 그 드라이버는 이제 고 처리량 및 저 대기시간 디바이스를 위해 사용될 수 없는데, 그 이유는, 일부 운영 체제들에서, 하드웨어 인터럽트가 사용자 모드 프로세스에 효율적으로 전달될 수 없기 때문이다. 다른 운영 체제들에서, 사용자 모드 드라이버의 성능은 커널 모드 드라이버보다 상당히 더 나쁘다.
하드웨어 제조업체들은 전형적으로 자유 형식의 하드웨어 사양(free form hardware specification)에 하드웨어를 설명하고 있다. 드라이버 개발자들은 하드웨어 액세스 계층을 개발하기 위해 이들 사양을 사용한다. 이 계층은 드라이버가 디바이스 레지스터 및 공유 메모리와 상호작용할 수 있게 한다. 이 계층을 개발하는 것은, 사양의 품질 및 개발자의 경험에 의존하기 때문에, 지루하기도 하고 오류를 발생시킬 수도 있다. 대부분의 경우에, 이 계층은 운영 체제 의존적이고, 다른 플랫폼들에 의해 사용될 수 없다.
본 명세서에 청구된 발명 요지는 임의의 단점들을 해결하거나 앞서 기술된 것들과 같은 환경들에서만 동작하는 실시예들로 제한되지 않는다. 오히려, 이 배경 기술은 본 명세서에 기술된 일부 실시예들이 실시될 수 있는 하나의 예시적인 기술 분야를 설명하기 위해 제공될 뿐이다.
본 명세서에 예시된 하나의 실시예는 하드웨어 디바이스와 상호작용하기 위해 디바이스 드라이버에 의해 사용되는 코드를 자동으로 생성하는 동작들을 포함하는, 컴퓨팅 환경에서 실시되는 방법을 포함한다. 이 방법은 하드웨어 디바이스의 하드웨어 레지스터들 또는 공유 메모리 구조들 중 적어도 하나를 포함한 하드웨어 디바이스의 기계 판독가능 설명(machine readable description)을 수신하는 단계를 포함한다. 이 방법은 하드웨어 디바이스가 사용될 운영 체제를 결정하는 단계를 추가로 포함한다. 이 방법은 결정된 운영 체제에 특유한 하드웨어 디바이스의 하드웨어 드라이버를 위한 코드를 자동으로 생성하기 위해 코드 생성 도구에서 기계 판독가능 설명을 처리하는 단계를 추가로 포함한다.
이 발명의 내용은 이하에서 발명을 실시하기 위한 구체적인 내용에 추가로 기술되는 개념들 중 선택된 것을 간략화된 형태로 소개하기 위해 제공된다. 이 발명의 내용은 청구된 발명 요지의 중요 특징들 또는 필수적인 특징들을 확인하기 위한 것이 아니며, 청구된 발명 요지의 범주를 정하는 데 보조 수단으로 사용되기 위한 것도 아니다.
부가의 특징들 및 이점들이 이하의 발명을 실시하기 위한 구체적인 내용에서 기술될 것이며, 부분적으로 발명을 실시하기 위한 구체적인 내용으로부터 명백하게 되거나 본 명세서의 발명 내용의 실시에 의해 알게 될 수 있다. 본 발명의 특징들 및 장점들이 첨부된 청구범위에 상세히 언급되어 있는 수단들 및 조합들에 의해 실현되고 달성될 수 있다. 본 발명의 특징들이 이하의 발명을 실시하기 위한 구체적인 내용 및 첨부된 청구범위로부터 더욱 명백하게 되거나, 이후에 기술되는 바와 같이 본 발명의 실시에 의해 알게 될 수 있다.
앞서 언급한 장점들 및 특징들과 기타 장점들 및 특징들이 달성될 수 있는 방식을 설명하기 위해, 이상에서 간략히 설명한 발명 요지의 보다 상세한 설명이 첨부 도면에 예시되어 있는 구체적인 실시예들을 참조하여 행해질 것이다. 이들 도면이 전형적인 실시예들만을 도시하고 있고 따라서 범주를 제한하는 것으로 간주되어서는 안된다는 것을 이해하면서, 실시예들이 첨부 도면을 사용하여 보다 구체적이고 상세하게 기술되고 설명될 것이다.
도 1은 디바이스 하드웨어 및 자동 디바이스 하드웨어 추상화 계층 인터페이스 생성을 나타낸 도면.
도 2는 계층적 드라이버 생성을 나타낸 도면.
도 3은 버스 드라이버 프레임워크를 나타낸 도면.
도 4는 드라이버 인터럽트 및 디바이스 통신을 나타낸 도면.
도 5는 디바이스 드라이버에 대한 코드를 자동으로 생성하는 방법을 나타낸 도면.
도 6은 하드웨어 드라이버에 대한 제한을 시행하는 방법을 나타낸 도면.
도 7은 고 처리량 및 저 대기시간 디바이스들을 지원할 수 있는 안전한 드라이버를 구현하는 방법을 나타낸 도면.
본 명세서에 개시된 실시예들은 모든 디바이스 유형들에 대한 고성능의 사용자 모드이고 타입 안정성 드라이버들의 개발을 용이하게 하는 다수의 기법들을 포함할 수 있다. 이 드라이버들은 다른 운영 체제들에 존재하는 레거시 커널 모드 디바이스 드라이버들과 비슷한 성능을 발휘한다.
일부 실시예들은 디바이스 드라이버 자동 생성 하드웨어 추상화 계층(auto-generating device driver hardware abstraction layer)을 구현할 수 있다. 도 1에 예시된 바와 같이, 하드웨어 디바이스(102)는 CPU(108) 내의 레지스터들(106) 및 시스템 메모리(112) 내의 공유 메모리(110)를 사용하여 컴퓨팅 시스템(104)과 인터페이스한다. 하드웨어 디바이스는 전형적으로 특정의 메모리 상호작용에 의해 레지스터들(106)의 세트 내의 특정의 레지스터들과 인터페이스하도록 정적 방식으로 제작된다. 시스템(104) 및 레지스터들(106) 및 공유 메모리(110)가 하드웨어 디바이스(102)와 적절히 인터페이스하도록 보장하기 위해, 시스템 하드웨어와 디바이스 하드웨어 간의 매핑을 제공하는 드라이버(114)가 사용된다. 드라이버(114)는 전형적으로 제조업체가 제공한 텍스트 사양을 사용하여 수동으로 개발된다.
하드웨어 제조업체들은 전형적으로 자유 형식의 하드웨어 사양에 하드웨어를 설명하고 있다. 드라이버 개발자들은 하드웨어 액세스 계층을 개발하기 위해 이들 사양을 사용한다. 살펴본 바와 같이, 이 계층은 드라이버가, DMA(direct memory access)를 사용하는 등에 의해, 디바이스 레지스터들 및 공유 메모리와 상호작용할 수 있게 한다. 이 계층을 개발하는 것은, 사양의 품질 및 개발자의 경험에 의존하기 때문에, 지루하기도 하고 오류를 발생시킬 수도 있다. 대부분의 경우에, 이 계층은 운영 체제 의존적이고, 다른 플랫폼들에 의해 사용될 수 없다.
본 명세서에서의 일부 실시예들은 하드웨어 액세스 계층 사양(hardware access layer specification)과 그의 구현을 분리시키기 위해 하드웨어 추상화 메커니즘을 구현하는 것에 의해 드라이버 개발을 단순화시킨다. 기계 판독가능 하드웨어 사양(116)이 디바이스 공급업체에 의해 제공될 수 있다. 기계 판독가능 하드웨어 사양이 코드 생성 도구(118)에 의해 처리된다. 코드 생성 도구(118)는 하나 이상의 상이한 운영 체제들에 대한 운영 체제 컨텍스트(operating system context)를 가지며, 따라서 기계 판독가능 하드웨어 사양(116)을 처리하는 것에 의해 하드웨어 디바이스 인터페이스 계층을 자동으로 생성할 수 있다. 이와 같이, 기계 판독가능 하드웨어 사양(116)이 각종의 상이한 프로그래밍 언어들을 사용하여 다수의 상이한 운영 체제들에 대한 하드웨어 디바이스 인터페이스 계층들(115-1, 115-2 내지 115-n)을 생성하는 데 재사용될 수 있다. 이 방식은 드라이버 개발을 크게 단순화시키고 잘못된 하드웨어 액세스에 의해 야기되는 오류들의 양을 감소시킨다. 기계 판독가능 하드웨어 사양(116)은 C#과 같은 간단한 언어로 작성될 수 있고, 검사를 통해 쉽게 확인될 수 있다.
이와 같이, 개발자 또는 하드웨어 제조업체는 디바이스(102) 하드웨어 레지스터들 및 (호스트 메모리 내의) 공유 메모리 구조들을 하드웨어-소프트웨어 인터페이스 언어를 사용하여 설명할 수 있다. 이를 위해, 개발자는 텍스트 하드웨어 사양을 참고한다. 유의할 점은, 하드웨어 엔지니어 또는 하드웨어 공급업체가 또한 기계 판독가능 하드웨어 사양(116)의 하드웨어-소프트웨어 인터페이스 설명을 제공할 수 있다는 것이다. 상세하게는, 드라이버 개발자가 하드웨어-소프트웨어 인터페이스 언어를 사용하여 기계 판독가능 하드웨어 사양(116)을 규정하기 위해 하드웨어 설명 단계에 관여될 필요가 없다. 제2 단계에서, 하드웨어-소프트웨어 인터페이스 프로세서(120)를 포함하는 코드 생성 도구(118)에 의해 하드웨어 설명이 처리된다.
하드웨어-소프트웨어 인터페이스 프로세서(120)는, 이하에서 예시되는 바와 같이, 다양한 소프트웨어 드라이버 모듈들을 생성할 수 있다.
하드웨어-소프트웨어 인터페이스 프로세서(120)는 레지스터들을 판독/기입하고 그의 필드들을 해석하기 위한 하드웨어 액세스 방법들을 생성할 수 있다. 예를 들어, 기계 판독가능 하드웨어 사양(116)에 기초하여, 코드 생성 도구(118)는 레지스터들(106)의 세트 내의 어느 레지스터들이 하드웨어 디바이스(102)와 통신하는 데 사용되는지를 결정할 수 있다. 방법들은 이들 레지스터에 액세스하기 위해 생성될 수 있고, 각각의 레지스터의 목적 및 각각의 레지스터 내의 데이터의 해석을 알려주기 위해 하드웨어 디바이스(102)를 제어하고자 하는 애플리케이션에 소프트웨어 인터페이스들을 제공하는 데 사용될 수 있다.
하드웨어-소프트웨어 인터페이스 프로세서(120)는 공유 구조체의 필드들을 판독/기입하기 위한 방법들을 생성할 수 있다. 예를 들어, 기계 판독가능 하드웨어 사양(116)에 기초하여, 코드 생성 도구(118)은, 드라이버 소프트웨어 모듈들에서, 하드웨어 디바이스(102)에 의해 사용될 공유 메모리(110)의 부분들을 식별할 수 있다. 이것은 소프트웨어 애플리케이션이 드라이버(114)를 사용하여, 하드웨어 디바이스(102)에 의해 사용되는 공유 메모리(110)의 부분들과 통신할 수 있게 할 수 있게 한다.
하드웨어-소프트웨어 인터페이스 프로세서(120)는 하드웨어-소프트웨어 인터페이스 설명에 표현된 하드웨어 인터페이스 엔터티들에 대한 메모리 할당기(memory allocator)들을 생성할 수 있다. 예를 들어, 기계 판독가능 하드웨어 사양(116)에 기초하여, 코드 생성 도구(118)는 어느 하드웨어 인터페이스들이 하드웨어 디바이스(102)에 포함되어 있는지를 알게 된다. 따라서 하드웨어 인터페이스들의 사용을 위한 시스템 메모리(112) 내의 메모리를 할당하기 위해 메모리 할당기들을 포함하도록 하드웨어 인터페이스 계층(115)이 자동으로 생성될 수 있다.
하드웨어-소프트웨어 인터페이스 프로세서(120)는 하드웨어 인터페이스 엔터티들을 해석하고 추적하는 로그 모듈(log module)들을 생성할 수 있다. 예를 들어, 기계 판독가능 하드웨어 사양(116) 및 하드웨어 디바이스(102)의 하드웨어 인터페이스들에 관한 지식에 기초하여, 코드 생성 도구(118)는 하드웨어 디바이스(102)의 하드웨어 동작들을 로깅하는 데이터를 수집하고 로깅하기 위해 하드웨어 인터페이스들을 사용할 수 있는 모듈들을 포함하도록 하드웨어 인터페이스 계층(115)을 자동으로 생성할 수 있다.
하드웨어-소프트웨어 인터페이스 프로세서(120)는 하드웨어 인터페이스 엔터티들을 시각화하는 디버거 확장(debugger extension)들을 생성할 수 있다. 예를 들어, 기계 판독가능 하드웨어 사양(116) 및 하드웨어 디바이스(102)의 하드웨어 인터페이스들에 관한 지식에 기초하여, 코드 생성 도구(118)는 디버깅을 위해 사용될 수 있는 하드웨어 디바이스(102)의 하드웨어 동작들을 로깅하는 데이터를 수집하고 로깅하기 위해 하드웨어 인터페이스들을 사용할 수 있는 모듈들을 포함하도록 하드웨어 인터페이스 계층(115)을 자동으로 생성할 수 있다.
이하는 USB EHCI 제어기 기능 레지스터(controller capability register)들의 하드웨어-소프트웨어 인터페이스 샘플 설명을 예시한 것이다.
/// <summary>
/// These registers specify the limits, restrictions and capabilities of the host controller implementation.
/// </summary>
[MemoryMappedRegister(ResourceType.MemoryRange, Size = 0xC)]
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;
}
살펴본 바와 같이, 이 다이어그램은 USB EHCI 제어기 레지스터들의 샘플 설명을 보여주고 있다. 제시되는 레지스터는 기능 레지스터(capability register)이다. 각각의 레지스터는 디바이스 메모리 기준 주소(device memory base address)에 대해 어떤 오프셋에 위치해 있다. 이 예에서, 기능 레지스터는 하드웨어-소프트웨어 구문(hardware-software syntax)의 일부인 "MemoryMappedRegister" 속성(attribute)에 의해 명시된 바와 같이 오프셋 0xC에 위치해 있다. 레지스터의 기준 주소가 설정되면, 하드웨어-소프트웨어 인터페이스는 상이한 레지스터 필드들을 제시하기 위해 몇 가지 속성들을 제공한다. 이 예에서, "DataField" 속성은 기능 레지스터의 일부인 레지스터들을 표현하기 위해 사용된다. 예를 들어, HCSPARAMS는 (설명된 바와 같이 0xC에 있는) 기능 레지스터의 기준 주소로부터 오프셋 0x4에 위치된 레지스터이다. 각각의 데이터 필드는 (이하에 예시된 바와 같이) 하드웨어-소프트웨어 인터페이스 구문에 의해 재귀적으로 주석 첨부된다.
이하는 HCCPARAMS 레지스터 필드의 하드웨어-소프트웨어 인터페이스 설명을 예시한 것이다.
/// <summary> Host Controller Capability Parameters </summary>
[MemoryMappedRegister(Size = 4)]
struct HCCPARAMS
{
[ReservedBits(16, 31)] public uint Reserved1;
/// <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(1)] public uint ProgramableFrameList;
/// <summary>
/// 64-bit Addressing Capability.
/// </summary>
[BitField(0)] public bool Bit64Addressing;
}
이 다이어그램은 (앞서 제시된 기능 레지스터의 일부인) HCSPARAMS 레지스터가 어떻게 주석 첨부되는지를 보여주고 있다. 하드웨어-소프트웨어 인터페이스 "BitField" 및 "ReservedBits" 속성들은 개발자가 레지스터 비트들에 주석 첨부할 수 있게 한다. 예를 들어, 이 레지스터에서의 비트 0은 디바이스가 64 비트 주소를 지원하는지를 나타낸다. 개발자는 이 요구사항을 제시하기 위해 "[(BitField(0)] public bool Bit64Addressing;"을 사용한다. 생성된 코드는 개발자가 값을 질의하기 위해 부울 형식(Boolean)인 "Bit64Addressing"에 액세스할 수 있게 할 것이다.
이하는 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 = 0xc;
readonly IoMemory m_ioRange;
readonly int m_offset;
public EhciCapabilityRegisters(IoMemory mem, int offset = 0)
{
Contract.Requires(mem != null);
Contract.Requires(mem.Length >= SizeInBytes);
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); }
}
}
생성된 코드는 운영 체제 관련 인터페이스들을 사용하고 다른 운영 체제들에 대해 쉽게 생성될 수 있다.
이하는 생성된 코드가 디바이스 드라이버 코드에 의해 사용되는 방식을 예시하고 있다.
IoMemory mem = m_mappedIoRange. Memory AtOffset(0, EhciCapabilityRegisters.SizeInBytes, 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.Read();
int numberOfPorts = (int)m_structuralParameters.NumberOfPorts;
HCCPARAMS capabilityParameters = m_capabilityRegs.HCCPARAMS.Read();
bool is64Bit = capabilityParameters.Bit64Addressing;
if (is64Bit) { ... }
레지스터가 기본 메모리 영역(underlying memory region)으로 초기화되면, 레지스터가 쉽게 판독되고, 조작되며 디바이스에 라이트백(write back)될 수 있다.
앞서 설명한 예들에서, 생성된 코드는 임의의 운영 체제에 의해 사용될 수 있고, 특정의 공급업체로 제한되지 않는다. 그에 부가하여 또는 다른 대안으로서, 생성된 코드는 C#, Java, C, C++ 등과 같은 임의의 개발 언어로 되어 있을 수 있다.
살펴본 바와 같이, 일반적인 하드웨어-소프트웨어 인터페이스 언어는 하드웨어 레지스터들 및 (DMA를 통해 액세스가능한) 호스트 메모리 데이터 구조들을 기계 판독가능 하드웨어 사양에 설명하는 데 사용된다. 코드 생성기는 하드웨어-소프트웨어 인터페이스 설명에 대해 동작한다. 하드웨어-소프트웨어 인터페이스 설명이 하드웨어 공급업체들에 의해 제공되고, 확인되며 유지될 수 있다. 하드웨어 공급업체들은 하드웨어 설계로부터 직접 기계 판독가능 하드웨어 사양을 생성할 수 있어, 임의의 사람 오류의 가능성을 제거한다. 이것은 소프트웨어/하드웨어 인터페이스 설계 및 구현 경로들로부터의 사람의 개입을 감소시키거나 제거하고, 개발 시간을 단축시키며, 균일성 및 더 나은 디버깅 기능(debugging experience)을 제공한다.
일부 실시예들은 자원 강화(resource hardening)에 의해 기능 기반 드라이버 모델(capability based driver model)을 구현한다. 상세하게는, 대부분의 드라이버들(114)은 실제 하드웨어와 인터페이스한다. 이것을 달성하기 위해, 드라이버들(114)은 디바이스(102)에 존재하는 물리 메모리(122)의 일부를 컴퓨팅 시스템(104)의 가상 주소 공간에 매핑하거나, I/O 공간이라고 불리우는 전용 주소 공간을 사용한다. 이전에 예시된 기법들은 드라이버 코드가 디바이스(102)에 액세스하기 위해 매핑된 메모리(또는 I/O 포트)를 적절히 사용하도록 보장하는 데 도움을 주도록 구현된다. 많은 통상의 운영 체제들에서, 디바이스 드라이버들(114)은, 오류 또는 악의를 통해, 시스템 메모리(112) 내의 임의의 물리 주소를 매핑하고 사용하려고 자유롭게 시도할 수 있다. 드라이버 소프트웨어의 특권 속성으로 인해, 운영 체제는 전형적으로 드라이버(114)가 드라이버에 속하지 않는 또는 드라이버가 특정의 하드웨어 디바이스(102)를 제어하기 위해 적절히 기능하는 데 필요하지 않은 포트, 인터럽트, 또는 기타 인터페이스를 할당하지 않도록 보장할 방법이 없다. 예를 들어, 키보드 드라이버는 전형적으로 IR1 1에는 액세스해야만 하지만, 포트 80에는 액세스할 필요가 없다. 포트 80에 액세스하는 것에 의해, 불법적 키보드 드라이버는 키스트로크를 네트워크를 거쳐 불량 웹 사이트(rogue website)로 송신하는 것을 비롯한 키 로깅 기능(key-logging functionality)을 구현할 수 있다. 이것은 시스템 안정성을 위태롭게 할 수 있다.
본 명세서에서의 실시예들은 C# 또는 Java와 같은 관리 코드(managed code)로 드라이버들 및 시스템 프로세스들을 구현할 수 있다. 관리 코드는 샌드박스가 적용된 가상 기계(sandboxed virtual machine)의 관리 하에서만 실행하는 컴퓨터 프로그램 소스 코드이다. 그에 따라, 그렇게 구현된 임의의 드라이버들 또는 시스템 프로세스들은 닫힌 객체 공간(closed object space)을 포함한다. 디바이스 메모리 및 레지스터들이 드라이버가 초기화될 때 드라이버에 제공되는 전용 관리 객체(dedicated managed object)를 통해서만 액세스될 수 있다. 이와 같이, 드라이버는 드라이버가 디바이스를 제어하기 위해 적절히 기능하는 데 필요한 시스템 자원들 및 I/O 프로세스들에만 액세스할 수 있을 것이다.
다시 도 2를 참조하면, 일부 실시예들은 [메모리 매핑된 레지스터(206), I/O 포트(208), 및 DMA 버퍼(210)와 같은] 모든 I/O 자원들의 세트(204)가 기능(capability)인 접근법을 구현한다. 이들 기능은 커널(212)에 의해 배타적으로 소유되고, 시작(startup) 시에 시스템의 루트 버스 드라이버(root bus driver)(214)에 할당된다. 시스템의 루트 버스 드라이버(214)는 모든 I/O 자원들의 세트(204)의 서브셋들(204-1, 204-2 내지 204-n)을 다른 시스템 버스들(214-1, 214-2 내지 214-n)에 할당할 수 있다. 서브셋들(204-1 내지 204-n)은 버스들(214-1 내지 214-n)이 그에 접속(attach)될 특정의 디바이스들에 대해서만 필요로 하는 자원들만을 할당받는 방식으로 할당된다.
버스 드라이버들(214-1 내지 214-n)은, 그의 디바이스들을 열거(enumerate)할 때, I/O 자원들의 세트를 각각의 자식(child)에 할당한다. 예를 들어, 버스(214-1)는 디바이스들(202-1 및 202-2)이 그에 접속되어 있다. 버스(214-1)는 I/O 자원들의 세트(204-1-1)를 디바이스(202-1)에 그리고 자원들(204-1-2)의 세트를 디바이스(202-2)에 할당할 수 있고, 여기서 세트들(204-1-1 및 204-1-2)은 세트(204-1)의 서브셋이다. 버스는 그에 할당된 I/O 자원들만을 할당할 수 있다. 이 접근법은 드라이버가 그에 할당된 자원들만을 사용하거나 이전할 수 있도록 보장하기 위해 사용될 수 있는 계층적 I/O 자원 할당 방식을 제공한다. 이것은 시스템 안정성(system reliability)을 크게 향상시킬 수 있고, 운영 체제가 임의의 I/O 자원을 언제라도 쉽게 추적하고 취소할 수 있게 할 것이다. 드라이버가 종료되거나 끝날 때, 그의 자원들이 그의 부모 버스 드라이버(parent bus driver)에 의해 쉽게 회수될 수 있다. 입출력 메모리 관리 유닛(input/output memory management unit)(IOMMU) 하드웨어에 의해, 이 방식이 하드웨어 레벨에서 시행될 수 있다. 예를 들어, 디바이스를 잘못된 메모리 주소(illegal memory address)로 프로그램하려고 시도하는 드라이버 개발자가 시스템 안정성을 위태롭게 할 수 없을 것이다.
도 3은 전형적인 버스 드라이버(302)의 구조를 나타낸 것이다. 버스 드라이버(302)(이 예에서, PCI 버스 드라이버)는 모든 드라이버 서비스들을 제공하는 사용자 레벨 라이브러리(예컨대, 이 예에서, 미국 워싱턴주 레드몬드 소재의 Microsoft Corporation으로부터 입수가능한 DriverFramework 라이브러리)와 링크되어 있다. 드라이버는 또한 버스 드라이버(302)가 그의 자식 디바이스들을 열거할 수 있게 하는 플러그 앤 플레이 관리자 라이브러리(plug and play manager library)(306)와 링크되어 있다. 각각의 열거된 디바이스에 대해, 프레임워크는 할당된 디바이스의 자원을 보유하는 버스 슬롯(bus slot)[예시적인 버스 슬롯(308-1) 등]이라고 불리우는 추상화(abstraction)를 생성한다. 각각의 버스 드라이버는 런타임(runtime)에 의해 자식 드라이버들(예시적인 114-1로 예시됨)에 접속되는 예시적인 버스 슬롯 인터페이스(310-1)(IBusSlot 인터페이스로서 표시되어 있음)와 같은 다수의 버스 슬롯 인터페이스들을 내보내기(export)한다. 열거된 디바이스 드라이버를 제외한 다른 서비스 또는 프로세스는 버스 슬롯 인터페이스에 접속할 수 없다. 버스 슬롯 인터페이스는 자식 디바이스 드라이버에 의해 그의 할당된 I/O 자원들을 디바이스[예시적인 디바이스(102-1)에 의해 예시됨]에 할당하기 위해 사용된다. 드라이버는 부모 드라이버에서 버스 슬롯에 명시되는 I/O 자원들만을 할당할 수 있다.
이 메커니즘은 I/O 자원 관리가, 커널 또는 단일의 시스템 서비스에서가 아니라, 각각의 버스 드라이버에서 로컬적으로 실행된다는 점에서 구현 및 배포가 용이할 수 있다.
기능으로서 취급되는 I/O 자원들 이외에, 실시예들은 다양한 서비스들의 연결(connectivity)을 제어할 수 있는 운영 체제를 구현할 수 있다. 드라이버들이 서비스로서 취급되기 때문에, 실시예들은 드라이버가 사용/상호작용할 수 있는 서비스들의 세트를 제어할 수 있다. 예를 들어, 다른 운영 체제들과 달리, 일부 실시예들에서, 드라이버가 메시지를 다른 드라이버로 송신할 수 없는데, 그 이유는 드라이버가 (메시지를 그 서비스로 송신하는 인터페이스인) 그렇게 하는 기능을 갖지 않기 때문이다. 일부 실시예들의 운영 체제는 드라이버와 시스템 내의 다른 구성요소들 간의 연결을 제약하고, 제어하며, 관찰하고, 추론할 수 있다. 기능 기반 모델과 관리 코드의 사용의 조합은 본 명세서에 예시된 바와 같이 다양한 장점들을 제공한다.
도 4를 참조하면, 고유의 아키텍처가 예시되어 있다. 예시된 예에서, 사용자 모드(402)[예컨대, x86 아키텍처의 특권 링(privilege ring) 중 최소 특권(least privileged)의 링 3] 및 커널 모드(404)가 예시되어 있다. 마이크로커널(microkernel)(406)이 커널 모드(404)[때때로 수퍼바이저 모드(supervisor mode)라고 지칭됨]에서 구현될 수 있다. 마이크로커널(406)은 하위 레벨 주소 공간 관리(low-level address space management), 스레드 관리, 및 IPC 통신과 같은 메커니즘을 제공하는 최소량의 소프트웨어이다. 마이크로커널(406)은 기본 하드웨어 테이블(basic hardware table)을 판독하는 일을 맡고 있다.
사용자 모드(402)에서, 주소 공간은 예시적인 도메인(408-1)(본 명세서에서 총칭하여 408이라고 지칭됨)과 같은 도메인(domain)으로 분할된다. 도메인은 런타임[예시적인 런타임(412-1-1) 등] 상에서 하나 이상의 드라이버 프로세스들을 비롯한 다양한 프로세스들[예시적인 프로세스(410-1-1) 등, 총칭하여 410이라고 지칭됨]을 실행한다. 드라이버들이 고 처리량 및 저 대기시간 디바이스들을 지원할 수 있는 (드라이버들을 C# 또는 Java와 같은 관리 코드로 코딩하는 것 등에 의한) 사용자 모드(402) 관리 프로세스(410)인 실시예들이 구현될 수 있다. 일부 실시예들에서, 디바이스 드라이버들을 비롯한 모든 서비스들이 관리 코드 라이브러리들을 사용하여 개발되고, 사용자 모드(402)에서 실행된다. 그에 부가하여, 프로세스들(410)과 마이크로커널(406) 간의 격리(isolation)가 언어의 정적으로 검증되는 타입 안정성(statically verified type safety)을 통해 추가적으로 달성될 수 있다. 이 메커니즘은, 모든 프로세스들이 단일의 주소 공간 또는 도메인(408)에 존재하기 때문에, 복사 없이 IPC(inter-process communication) 채널을 통한 데이터의 교환을 가능하게 한다. 이러한 접근법은 타입 안정성 언어(type safe language)에 기초하지 않는 종래의 시스템에서 안전하게 만들기 어렵다.
관리 코드를 사용하여 구현되는 사용자 모드 드라이버는 시스템 안정성을 크게 증가시키고 드라이버 개발을 단순화시킬 수 있다. 상세하게는, 개발자는 시스템에서 이용가능한 임의의 사용자 모드 라이브러리(XML 파서, 큐 관리 등을 포함함)를 이용할 수 있다. 종래의 운영 체제들에서, 드라이버들이 그의 주소 공간을 커널과 공유해야만 하기 때문에, 드라이버 개발자들은 메모리 제약조건들 및 기타 제한들로 인해 임의의 기존의 라이브러리를 사용할 수 없었다. 그에 부가하여, 개발자들은 메모리 관리에 관해 더 이상 걱정할 필요가 없다. 프로세스 메모리를 관리하는 동일한 가비지 수집기(garbage collector)가 드라이버들에 대해 사용된다. 부적절한 메모리 관리는 운영 체제 오류들의 최대 원인들 중 하나이다. 일부 실시예 시스템들에서, 드라이버 메모리 관련 버그들이 제거될 수 있다.
일부 예시적인 실시예들에서, 하나 이상의 프로세스들(410)로 구현되는 드라이버들이 단일 스레드(single threaded)이다. 이와 같이, 개발자는 동기화, 스레드, 및 인터럽트 레벨에 관해 걱정할 필요가 없다. 드라이버 복잡도의 많은 부분이 사라지고, 개발자는 드라이버의 기능에 집중한다.
드라이버들이 표준의 타입 안정성 인터페이스들을 통해 액세스될 수 있다. 통상의 운영 체제들은 드라이버들에의 액세스를 Open, Close, Read, Write 및 범용 인터페이스[('ioctl'라고 알려진) DeviceIoControl 등]와 같은 몇 개의 사전 정의된 함수들로 제한한다. 이전의 시스템들에서, 드라이버들이 몇 개의 기지의 하드웨어 구성요소들을 제어했고, 그들이 수행하는 작업들이 제한되었지만, 이것이 적어도 일부 하드웨어 디바이스들(예컨대, 그래픽 가속기와 같은 하드웨어 가속기)이 확장적이고 복잡한 인터페이스를 그의 호스트에 노출시키는 최근의 시스템들에는 비효율적이다. 일부 실시예 운영 체제들에서 제공되는 해결책은 드라이버들을 일급 객체(first class-citizen)로서 취급한다.
프로세스(410)로서 구현되는 드라이버는 임의의 다른 시스템 서비스와 같은 타입 안정성 인터페이스들을 통해 액세스된다. 이러한 구현은 언어의 타입 안정성 특징들을 이용하고, 컴파일 타임(compile time)에 오류 있는 방법 호출을 잡아낸다. 컴파일 타임 타입 검사(compile-time type checking)를 제공하기 위해, 컴파일러는 코드에 있는 변수들 또는 표현식들에 대한 데이터 타입 정보를 알 필요가 있다. 인터페이스들은 인터페이스 소비자(interface consumer)와 인터페이스 구현(interface implementation) 간의 계약을 제공한다. 방법 시그너처(method signature)가 컴파일 동안 정적으로 검사될 수 있다. 상이한 타입으로 된 파라미터(differently-typed parameter)들의 불일치가 실행 중인 시스템에서 전혀 일어날 수 없다. 그에 부가하여, 그 오류들이 컴파일 타임에 애플리케이션 개발자에 의해 포착되고, 커널 모드(404)에서 드라이버 개발자에 의한 런타임 검사를 필요로 하지 않는다.
안정성 및 개발 용이성 이외에, 실시예들은 디바이스 드라이버들이 통상의 커널 모드 디바이스 드라이버들과 비슷한 고 처리량 및 저 대기시간을 달성할 수 있게 한다. 이것은 무복사 I/O 경로(zero-copy I/O path)를 구현할 수 있는 것에 의해 달성될 수 있다. "무복사"는 시스템에 들어가는 데이터가 메모리에 한번만 기입되고 이어서, 데이터를 복사할 필요 없이, 운영 체제 내에서도 애플리케이션 코드 내에서도, 많은 추상화 계층들에 의해 직접 사용될 수 있다는 사실을 말한다. 무복사 I/O 경로는 CPU가 하나의 메모리 장소로부터 다른 메모리 장소로의 복사를 수행하지 않는 경로이다. 오히려, CPU는 다른 작업들을 수행할 수 있다. 이것은 복사를 달성하기 위해 시스템을 사용자 모드(402)와 커널 모드(404) 사이에서 전환시키기 위해 컨텍스트 전환(context switch)을 갖지 않아도 될 수 있게 한다. 이하에서는 이제부터 관리 사용자 모드 디바이스 드라이버(managed, user-mode device driver)가 무복사 I/O 경로를 사용하여 이러한 성능을 달성할 수 있게 하는 기법들을 설명한다.
실시예들은 효율적인 인터럽트 디스패칭(interrupt dispatching)을 수행하도록 구성될 수 있다. 하드웨어 인터럽트를 사용자 모드 드라이버에 효율적으로 전달할 수 있는 것은 신규의 것이다. 인터럽트 디스패칭은 운영 체제 마이크로커널, 도메인 커널 및 드라이버의 프레임워크 라이브러리 간의 밀접한 상호작용에 의해 실행된다.
인터럽트를 디스패치하는 메커니즘은 I/O 인터럽트 관리자, 드라이버 프레임워크 라이브러리, 및 효율적인 마이크로커널 인터럽트 처리를 포함하는 3-계층 아키텍처를 사용한다.
도 4에 예시된 바와 같이, 각각의 도메인(408)은 도메인 커널 - 그의 일례가 414-1에 예시되어 있음(그러나 본 명세서에서 총칭하여 414라고 지칭됨) - 을 포함한다. I/O 인터럽트 관리자 - 그의 일례가 416-1에 예시되어 있음(그러나 본 명세서에서 총칭하여 416이라고 지칭됨) - 는 도메인 커널(414)의 일부이고 하드웨어 디바이스(102)와 디바이스 드라이버 프로세스들(410) 사이를 연결(bridge)한다. 이는 IRQ들(418)에 디바이스 드라이버들을 등록하는 것을 관리하는 일, 인터럽트들을 드라이버 프로세스들(410)로 디스패치하는 일, 및 IRQ가 다수의 디바이스들에 의해 공유될 때 인터럽트 공유를 처리하는 일을 맡고 있다. 모든 디바이스 드라이버들이 프로세스들에서 실행될 때, 실시예들은 디바이스 드라이버들이 커널에서 실행되는 종래의 모놀리딕 OS 커널 설계(monolithic OS kernel design)보다 드라이버들에 대한 더 강한 격리 및 장애 억제(fault containment)를 시행할 수 있다.
드라이버 프레임워크 라이브러리는 통지를 수신하기 위해 도메인 커널(414)에 인터럽트 핸들러를 등록하는 일을 맡고 있다. 하드웨어 인터럽트가 도메인 커널(414)에 수신될 때, 인터럽트 핸들러가 트리거되고, 사전 등록된 드라이버 루틴이 호출된다. 방법를 호출하는 것의 오버헤드가 아주 낮은데, 그 이유는 사용자 모드(402)와 커널 모드(404) 간의 컨텍스트 전환이 수반되지 않기 때문이다.
실시예들은 효율적인 마이크로커널 인터럽트 처리를 구현한다. 일부 실시예들에서, 마이크로커널(406)은 인터럽트가능(interruptible)하지만 선점가능(preemptable)하지 않다. 논리 프로세서는, 마이크로커널(406)의 컨텍스트에서 실행 중인 동안, 인터럽트들을 수신할 수는 있지만, 그의 컨텍스트를 차단 또는 전환할 수 없다. 인터럽트 디스패치 대기시간을 최소화하기 위해, 실시예들은 프로세서가 마이크로커널(406) 내부에서 소비할 수 있는 시간량을 제한한다. 일부 실시예들은 어쩌면 사전 설정된 한계보다 더 긴 시간이 걸릴 수 있는 시스템 호출들에 대해 연속 실행 방식을 구현한다. 한계 및 연속 방식은 마이크로커널(406)이 인터럽트를 아주 낮은 대기시간으로 도메인 커널(414)로 전달할 수 있게 한다. 모든 하드웨어 인터럽트들(MSI, IRQ 및 Virtual)이 드라이버의 일부인 사용자 모드 라이브러리로 전달된다. 인터럽트 디스패치 대기시간을 최소화하는 것은, 일부 실시예들에서, 무복사 I/O 경로를 사용하는 것에 의해 달성될 수 있다.
무복사 I/O 경로의 하나의 예시적인 예가 이제부터 설명된다. 도 1을 다시 참조하면, 시스템 메모리(112)가 예시되어 있다. 프로세스(410)는 시스템 메모리(112)의 일부분을 할당할 수 있다. 마이크로커널(406)(도 4 참조)은 프로세스(410)가 메모리를 할당할 수 있게 할 수 있지만, 메모리가 프로세스(410)에 할당되면, 프로세스(410)는 시스템 메모리의 일부분을 제어한다. 하드웨어 드라이버 예에서, 하드웨어 디바이스(102)는 메모리의 일부분에 기입할 수 있다. 드라이버 프로세스(410)는 이어서 메모리의 이 부분을 변경불가능(immutable)으로서 표시할 것이다. 변경불가능인 메모리는 그의 내용 및/또는 주소가 변경될 수 없는 메모리이다. 메모리의 일부분이 변경불가능하기 때문에, 메모리의 일부분에 액세스하는 것에 대한 실제 제약조건이 없다. 이와 같이, 시스템은 상이한 프로세스들이 메모리로부터 판독할 수 있게 하기 위해 커널 모드로 전환할 필요가 없다. 이와 같이, 드라이버 프로세스(410)는 컨텍스트 전환을 필요로 함이 없이 메모리의 일부분에 액세스할 수 있고, 따라서 메모리의 일부분에 기입하는 하드웨어 디바이스(102)로부터 데이터를 신속하고 효율적으로 획득할 수 있으며, 그에 따라 드라이버가 사용자 모드에서 구현될 때 높은 효율 및 낮은 대기시간이 여전히 달성될 수 있다.
메모리의 변경불가능 부분의 상이한 뷰들을 제공하는 것에 의해, 데이터가 상이한 프로세스들(410)로 적절한 방식들로 전달될 수 있다. 이와 같이, 특정의 프로세스(410)에 필요한 데이터의 일부분을 복사하기보다는, 메모리의 변경불가능 부분에 대한 포인터들이 사용될 수 있고, 메모리의 변경불가능 부분에 있는 데이터의 논리적 뷰들이 해당 데이터를 제공할 수 있다. 이와 같이, 특정의 프로세스(410)의 관점에서, 데이터가 적절한 포맷으로 복사되어 제공된 것처럼 보이지만, 실제로는, 데이터 복사가 일어나지 않았다.
드라이버 프로세스(410)가 데이터를 하드웨어 디바이스(102)로 보내기 위해 유사한 기능이 사용될 수 있다. 상세하게는, 드라이버 프로세스(410)는 데이터를 시스템 메모리(112)의 일부분에 기입할 수 있다. 그 부분은 동일한 드라이버 프로세스(410) 또는 다른 드라이버 프로세스에 의해 변경불가능으로서 표시될 수 있다. 시스템을 커널 모드(404)로 전환할 필요 없이, 메모리가 이어서 하드웨어 디바이스(102)에 의해 판독될 수 있다.
일부 실시예들에서, 메모리의 변경불가능 부분은 그와 연관된 카운터를 가질 수 있다. 프로세스가 메모리의 변경불가능 부분에 액세스할 때마다, 카운터가 증가된다. 프로세스가 메모리의 변경불가능 부분의 판독을 완료할 때, 카운터가 감소된다. 이와 같이, 메모리의 변경불가능 부분을 판독하고 있던 모든 프로세스들이 메모리의 변경불가능 부분과의 관계를 끝낸 후에, 카운터는 0으로 감소되고, 이는 메모리의 그 부분이 다른 메모리 동작을 위해 해제될 수 있게 한다.
다른 기법은 디바이스 제어를 위해 DMA 채널을 사용하는 것에 관련되어 있다. 채널은 채널 종단점이라고 불리우는 정확히 2개의 종단점을 가지는 양방향 메시지 통로이다. DMA 채널은 DMA를 통해 대량의 패킷화된 데이터를 교환하는 애플리케이션과 디바이스 드라이버 사이의 갭을 메우는 고성능 메커니즘이다. 이는 표준의 IPC(inter-process communication) 채널의 특수한 경우로서, 주된 차이점은 판독가능 DMA 동작 및 채널에서의 메시지의 비동기 폐기(retirement)를 제안하는 것이다. IPC 메시지는 두 부분 - 하나는 필수적이고 다른 하나는 선택적임 - 을 가진다. 필수적 부분은 채널의 슬롯에 복사되는 인라인 데이터(inline data)이고, 선택적 부분은 채널을 거쳐 전송되는(또는 채널을 통해 공유되는) 핸들(handle)을 포함한다. DMA 채널은 이하의 측면들에서 독특하다:
- 전적으로 (드라이버 및 프로세스가 살아 있는) 사용자 모드에서 실행된다.
- 백프레셔(back pressure)를 제공한다. 애플리케이션과 네트워크 드라이버 사이에서 전달되는 각각의 메시지에 대한 메모리 할당이 없다. 게다가, 데이터가 완전히 소비될 때까지 채널에 머물러 있을 수 있고, 이 데이터의 배후에 있는 메시지가 계속 처리될 수 있다.
- 무복사 지원을 포함한다. DMA가 링 버퍼(ring buffer)로부터 실행될 수 있다.
- 임의의 제어 메시지에 대한 지원을 포함한다. 이것은 소프트웨어 세그먼트화 오프로드(software segmentation offload)와 같은 최적화를 가능하게 한다.
이하의 논의는 이제부터 수행될 수 있는 다수의 방법들 및 방법 동작들을 언급한다. 방법 동작들이 특정의 순서로 논의되거나 특정의 순서로 일어나는 것으로 플로우차트에 예시되어 있지만, 특정의 순서가, 구체적으로 언급되지 않는 한, 요구되지 않거나, 동작이 그 동작이 수행되기 전에 다른 동작이 완료되는 것에 의존하기 때문에, 특정의 순서가 요구된다.
이제 도 5를 참조하면, 방법(500)이 예시되어 있다. 방법(500)은 컴퓨팅 환경에서 실시될 수 있다. 방법(500)은 하드웨어와 인터페이스하기 위해 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 동작을 포함한다. 방법(500)은 하드웨어 디바이스의 기계 판독가능 설명을 수신하는 단계[동작(502)]를 포함한다. 기계 판독가능 설명은 하드웨어 디바이스의 하드웨어 레지스터들 또는 공유 메모리 구조들 중 적어도 하나를 포함한다. 예를 들어, 도 1은 하드웨어 디바이스(102)의 기계 판독가능 설명(116)의 일례를 예시하고 있다.
방법(500)은 하드웨어 디바이스가 사용될 운영 체제를 결정하는 단계[동작(504)]를 추가로 포함한다. 예를 들어, 코드 생성 도구(118)는 하드웨어 인터페이스 계층(115)이 생성되고 있는 운영 체제를 설정하는 정보에 액세스할 수 있거나 그 정보를 가질 수 있다.
방법(500)은 결정된 운영 체제에 특유한 하드웨어 디바이스의 하드웨어 드라이버를 위한 코드를 자동으로 생성하기 위해 코드 생성 도구에서 기계 판독가능 설명을 처리하는 단계[동작(506)]를 추가로 포함한다. 예를 들어, 도 1은 코드 생성 도구(118)가 기계 판독가능 하드웨어 사양(116)을 실행하는 것을 나타내고 있다.
다양한 드라이버 코드 부분들이 생성될 수 있다. 예를 들어, 하드웨어 드라이버를 위한 코드를 생성하는 단계가 레지스터들을 판독하고 그에 기입하며 레지스터들의 필드들을 해석하는 하드웨어 액세스 방법들을 생성하는 단계를 포함하는 방법(500)의 일부 실시예들이 실시될 수 있다. 다른 대안으로서 또는 그에 부가하여, 하드웨어 드라이버를 위한 코드를 생성하는 단계가 공유 구조체의 필드들을 판독하고 그에 기입하는 방법들을 생성하는 단계를 포함하는 방법(500)의 실시예들이 실시될 수 있다. 다른 대안으로서 또는 그에 부가하여, 하드웨어 드라이버를 위한 코드를 생성하는 단계가 하드웨어 디바이스의 기계 판독가능 설명에 표현되는 하드웨어 인터페이스 엔터티들에 대한 메모리 할당기들을 생성하는 단계를 포함하는 방법(500)의 실시예들이 실시될 수 있다. 다른 대안으로서 또는 그에 부가하여, 하드웨어 드라이버를 위한 코드를 생성하는 단계가 하드웨어 인터페이스 엔터티들을 해석하고 추적하는 로그 모듈(log module)들을 생성하는 단계를 포함하는 방법(500)의 실시예들이 실시될 수 있다. 다른 대안으로서 또는 그에 부가하여, 하드웨어 드라이버를 위한 코드를 생성하는 단계가 하드웨어 인터페이스 엔터티들을 시각화하는 디버거 확장들을 생성하는 단계를 포함하는 방법(500)의 실시예들이 실시될 수 있다.
하드웨어 디바이스의 기계 판독가능 설명이 하드웨어 공급업체에 의해 제공되는 방법(500)의 일부 실시예들이 실시될 수 있다.
하드웨어 드라이버를 위해 생성된 코드가 관리 코드(managed code)로서 생성되는 방법(500)의 일부 실시예들이 실시될 수 있다.
이제 도 6을 참조하면, 방법(600)이 예시되어 있다. 방법(600)은 컴퓨팅 환경에서 실시될 수 있다. 방법(600)은 하드웨어 드라이버들에 대한 제한을 시행하는 동작을 포함한다. 방법(600)은, 시스템 커널로부터, I/O 자원들을 시스템의 루트 버스에 할당하는 단계[동작(602)]를 포함한다. 예를 들어, 도 2는 I/O 자원들을 버스 드라이버(214)에 할당하는 것에 의해 I/O 자원들이 시스템의 루트 버스에 할당되는 것을 나타내고 있다.
루트 버스로부터, 방법(600)은 I/O 자원들의 서브셋을 디바이스 버스에 할당하는 단계[동작(604)]를 포함한다. I/O 자원들의 서브셋을 디바이스 버스에 할당하는 단계는 디바이스 버스를 루트 버스에 의해 그에 할당되는 I/O 자원들만을 할당할 수 있도록 제한하는 단계를 포함한다. 예를 들어, 도 2에서, 디바이스 버스들(214-1 내지 214-n)은 그에 할당된 자원들을 가진다. 이들 디바이스 버스 각각은 그에게 할당된 자원들만을 추가로 할당할 수 있다.
방법(600)은, 디바이스 버스로부터, I/O 자원들을 디바이스 인터페이스를 통해 디바이스에 할당하는 단계[동작(606)]를 추가로 포함한다.
디바이스 버스를 루트 버스에 의해 그에 할당되는 I/O 자원들만을 할당할 수 있도록 제한하는 단계가 버스 드라이버들을 관리 코드로 구현하는 것에 의해 달성되는 방법(600)의 일부 실시예들이 구현될 수 있다.
I/O 자원들의 서브셋을 디바이스 버스에 할당하는 단계가 관리 코드로 구현된 버스 드라이버를 호출하는 단계를 포함하는 방법(600)이 실시될 수 있다.
I/O 자원들을 디바이스에 할당하는 단계가 관리 코드로 구현된 디바이스 드라이버를 호출하는 단계를 포함하는 방법(600)이 실시될 수 있다.
방법(600)은 다른 서비스들 및 프로세스들이 디바이스 인터페이스에 접속하지 못하게 하는 단계를 추가로 포함할 수 있다.
이제 도 7을 참조하면, 방법(700)이 예시되어 있다. 방법(700)은 컴퓨팅 환경에서 실시될 수 있다. 방법(700)은 고 처리량 및 저 대기시간 디바이스들을 지원할 수 있는 타입 안정성 드라이버(type safe driver)를 구현하는 동작을 포함한다. 방법(700)은 하드웨어 디바이스로부터 데이터를 수신하는 단계[동작(702)]를 포함한다. 방법(700)은 하나 이상의 드라이버 프로세스들이 고 처리량 및 저 대기시간 하드웨어 디바이스들을 지원할 수 있게 하기 위해 무복사를 사용하여 데이터를 사용자 모드에서 실행 중인 하나 이상의 드라이버 프로세스들로 전달하는 단계[동작(704)]를 추가로 포함한다.
데이터를 전달하는 단계가 커널 모드를 선점하는 일 없이 수행되는 방법(700)이 실시될 수 있다. 다른 대안으로서 또는 그에 부가하여, 방법(700)은 프로세서가 커널 모드에서 소비하는 시간량을 제한하는 단계를 추가로 포함할 수 있다. 다른 대안으로서 또는 그에 부가하여, 드라이버 프로세스가 관리 코드로 구현되는 방법(700)이 실시될 수 있다. 다른 대안으로서 또는 그에 부가하여, 방법(700)은 사용자 모드에서 구현되는 I/O 인터럽트 관리자가 사용자 모드 디바이스 드라이버들을 인터럽트들에 등록하는 단계를 추가로 포함할 수 있다. 일부 실시예들에서, I/O 인터럽트 관리자는 인터럽트들을 드라이버 프로세스들로 디스패치한다. 다른 대안으로서 또는 그에 부가하여, 방법(700)은 드라이버들을 단일 스레드 프로세스들로서 구현하는 단계를 추가로 포함할 수 있다. 다른 대안으로서 또는 그에 부가하여, 하나 이상의 드라이버 프로세스들이, 어느 사용자 모드 라이브러리들이 하나 이상의 드라이버 프로세스들을 구현하는 데 사용될 수 있는지에 대한 제한 없이, 구현되는 방법(700)이 실시될 수 있다.
게다가, 방법들이 하나 이상의 프로세서들 및 컴퓨터 메모리와 같은 컴퓨터 판독가능 매체를 포함하는 컴퓨터 시스템에 의해 실시될 수 있다. 상세하게는, 컴퓨터 메모리는, 하나 이상의 프로세서들에 의해 실행될 때, 실시예들에서 언급된 동작들과 같은 다양한 기능들이 수행되게 하는 컴퓨터 실행가능 명령어들을 저장할 수 있다.
본 발명의 실시예들은, 이하에서 더 상세히 논의되는 바와 같이, 컴퓨터 하드웨어를 포함하는 특수 목적 또는 범용 컴퓨터를 포함하거나 이용할 수 있다. 본 발명의 범주 내의 실시예들은 또한 컴퓨터 실행가능 명령어들 및/또는 데이터 구조들을 전달하거나 저장하는 물리 및 기타 컴퓨터 판독가능 매체를 포함한다. 이러한 컴퓨터 판독가능 매체는 범용 또는 특수 목적 컴퓨터 시스템에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 컴퓨터 실행가능 명령어들을 저장하는 컴퓨터 판독가능 매체는 물리 저장 매체이다. 컴퓨터 실행가능 명령어들을 전달하는 컴퓨터 판독가능 매체는 전송 매체이다. 이와 같이, 제한이 아닌 예로서, 본 발명의 실시예들은 적어도 두 개의 서로 다른 종류의 컴퓨터 판독가능 매체 - 물리 컴퓨터 판독가능 저장 매체 및 전송 컴퓨터 판독가능 매체 - 를 포함할 수 있다.
물리 컴퓨터 판독가능 저장 매체는 컴퓨터 실행가능 명령어들 또는 데이터 구조들의 형태로 되어 있는 원하는 프로그램 코드 수단을 저장하는 데 사용될 수 있고 범용 또는 특수 목적 컴퓨터에 의해 액세스될 수 있는 RAM, ROM, EEPROM, CD-ROM 또는 기타 광 디스크 저장소(CD, DVD, 기타 등등), 자기 디스크 저장소 또는 기타 자기 저장 디바이스, 또는 임의의 다른 매체를 포함한다.
"네트워크"는 컴퓨터 시스템들 및/또는 모듈들 및/또는 기타 전자 디바이스들 간의 전자적 데이터의 전송을 가능하게 하는 하나 이상의 데이터 링크들로서 정의된다. 정보가 네트워크 또는 다른 통신 연결(유선, 무선 또는 유선 또는 무선의 조합)을 통해 컴퓨터로 전송되거나 제공될 때, 컴퓨터는 적절하게도 그 연결을 전송 매체로 본다. 전송 매체는 컴퓨터 실행가능 명령어들 또는 데이터 구조들의 형태로 되어 있는 원하는 프로그램 코드 수단을 전달하는 데 사용될 수 있고 범용 또는 특수 목적 컴퓨터에 의해 액세스될 수 있는 네트워크 및/또는 데이터 링크들을 포함할 수 있다. 상기한 것들의 조합이 또한 컴퓨터 판독가능 매체의 범주 내에 포함된다.
게다가, 다양한 컴퓨터 시스템 구성요소들에 도달할 때, 컴퓨터 실행가능 명령어들 또는 데이터 구조들의 형태로 되어 있는 프로그램 코드 수단이 전송 컴퓨터 판독가능 매체로부터 물리 컴퓨터 판독가능 저장 매체로(또는 그 반대로) 자동으로 전송될 수 있다. 예를 들어, 네트워크 또는 데이터 링크를 통해 수신되는 컴퓨터 실행가능 명령어들 또는 데이터 구조들이 네트워크 인터페이스 모듈(network interface module)(예를 들어, "NIC") 내의 RAM에 버퍼링될 수 있고, 이어서 궁극적으로 컴퓨터 시스템 RAM으로 및/또는 컴퓨터 시스템에 있는 저휘발성(less volatile) 컴퓨터 판독가능 물리 저장 매체로 전송될 수 있다. 이와 같이, 컴퓨터 판독가능 물리 저장 매체가 전송 매체를 또한(또는 심지어 주로) 이용하는 컴퓨터 시스템 구성요소들에 포함될 수 있다.
컴퓨터 실행가능 명령어들은, 예를 들어, 범용 컴퓨터, 특수 목적 컴퓨터, 또는 특수 목적 처리 디바이스로 하여금 특정의 기능 또는 일군의 기능들을 수행하게 하는 명령어들 및 데이터를 포함한다. 컴퓨터 실행가능 명령어들은, 예를 들어, 바이너리, 어셈블리어와 같은 중간 포맷 명령어(intermediate format instruction), 또는 심지어 소스 코드일 수 있다. 발명 요지가 구조적 특징들 및/또는 방법 동작들과 관련하여 기술되어 있지만, 첨부된 청구범위에 한정된 발명 요지가 상기한 기술된 특징들 또는 동작들로 꼭 제한되는 것은 아님을 잘 알 것이다. 오히려, 기술된 특징들 및 동작들은 청구항들을 구현하는 예시적인 형태들로서 개시되어 있다.
통상의 기술자라면 본 발명이 개인용 컴퓨터, 데스크톱 컴퓨터, 랩톱 컴퓨터, 메시지 프로세서, 핸드헬드 디바이스, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그램가능 가전 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 이동 전화, PDA, 페이저, 라우터, 스위치 등을 비롯한 많은 유형의 컴퓨터 시스템 구성들을 갖는 네트워크 컴퓨팅 환경들에서 실시될 수 있다는 것을 잘 알 것이다. 본 발명은 또한 네트워크를 통해 (유선 데이터 링크, 무선 데이터 링크에 의해, 또는 유선 및 무선 데이터 링크들의 조합에 의해) 연결되어 있는 로컬 및 원격 컴퓨터 시스템들 둘 다가 작업들을 수행하는 분산 시스템 환경들에서 실시될 수 있다. 분산 시스템 환경에서는, 프로그램 모듈들은 로컬 및 원격 메모리 저장 디바이스들 둘 다에 위치될 수 있다.
본 발명은 그의 사상 또는 특성들을 벗어남이 없이 다른 구체적인 형태들로 구현될 수 있다. 기술된 실시예들이 모든 점에서 제한적이 아니라 단지 예시적인 것으로 간주되어야 한다. 따라서, 본 발명의 범주는 이상의 설명이 아니라 첨부된 청구범위에 의해 나타내어진다. 청구범위의 등가성의 의미 및 범위 내에 속하는 모든 변경들이 청구범위의 범주 내에 포함된다.

Claims (20)

  1. 컴퓨팅 환경에서, 하드웨어와 인터페이스하기 위해 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법에 있어서,
    하드웨어 드라이버가 생성될 하드웨어 디바이스의 기계 판독가능 설명(description) - 상기 기계 판독가능 설명은 하드웨어-소프트웨어 인터페이스 언어로 기록되고, 복수의 상이한 가능한 운영 체제 각각에 대한 하드웨어 디바이스 인터페이스를 생성하기 위해 재사용 가능함 - 을 수신하는 단계;
    상기 복수의 상이한 가능한 운영 체제 각각에 대한 운영 체제 컨텍스트(operating system context)를 가진 코드 생성 도구를 인스턴스화하는(instantiating) 단계;
    상기 복수의 상이한 가능한 운영 체제로부터 그리고 상기 하드웨어 드라이버가 생성되기 전에, 상기 하드웨어 드라이버가 생성되고 상기 하드웨어 디바이스가 사용될 특정 운영 체제를 결정하는 단계; 및
    상기 하드웨어 디바이스에 대한 상기 하드웨어 드라이버를 위한 코드를 자동으로 생성 - 상기 생성된 코드는 상기 결정된 특정 운영 체제에 특유한 것이며 상기 결정된 특정 운영 체제에 특유한 운영 체제 인터페이스를 사용함 - 하기 위해, 상기 코드 생성 도구 및 상기 특정 운영 체제를 위한 운영 체제 컨텍스트를 사용하여 상기 기계 판독가능 설명을 처리하는 단계
    를 포함하는, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  2. 제1항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 레지스터를 판독하고 레지스터에 기입하고 상기 레지스터의 필드들을 해석하기 위한 하드웨어 액세스 방법들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  3. 제1항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 공유 구조체의 필드들을 판독하고 공유 구조체의 필드들에 기입하는 방법들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  4. 제1항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 상기 하드웨어 디바이스의 상기 기계 판독가능 설명에 표현되는 하드웨어 인터페이스 엔터티(hardware interface entity)들에 대한 메모리 할당기(meory allocator)들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  5. 제1항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 하드웨어 인터페이스 엔티티들을 해석 및 추적하는 로그 모듈들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  6. 제1항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 하드웨어 인터페이스 엔터티들을 시각화하는 디버거 확장(debugger extension)들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  7. 제1항에 있어서,
    상기 하드웨어 디바이스의 기계 판독가능 설명은 하드웨어 공급업체(vendor)에 의해 제공되는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  8. 기계 판독가능 명령어들을 저장한 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스에 있어서,
    상기 기계 판독가능 명령어들은, 하나 이상의 프로세서에 의한 실행시, 상기 하나 이상의 프로세서로 하여금,
    하드웨어 드라이버가 생성될 하드웨어 디바이스의 기계 판독가능 설명 - 상기 기계 판독가능 설명은 하드웨어-소프트웨어 인터페이스 언어로 기록되고, 복수의 상이한 가능한 운영 체제 각각에 대한 하드웨어 디바이스 인터페이스를 생성하기 위해 재사용 가능함 - 을 수신하는 것;
    상기 복수의 상이한 가능한 운영 체제 각각에 대한 운영 체제 컨텍스트를 가진 코드 생성 도구를 인스턴스화하는 것;
    상기 복수의 상이한 가능한 운영 체제로부터 그리고 상기 하드웨어 드라이버가 생성되기 전에, 상기 하드웨어 드라이버가 생성되고 상기 하드웨어 디바이스가 사용될 특정 운영 체제를 결정하는 것; 및
    상기 하드웨어 디바이스에 대한 상기 하드웨어 드라이버를 위한 코드를 자동으로 생성 - 상기 생성된 코드는 상기 결정된 특정 운영 체제에 특유한 것이며 상기 결정된 특정 운영 체제에 특유한 운영 체제 인터페이스를 사용함 - 하기 위해, 상기 코드 생성 도구 및 상기 특정 운영 체제를 위한 운영 체제 컨텍스트를 사용하여 상기 기계 판독가능 설명을 처리하는 것
    을 수행하게 하는 것인, 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스.
  9. 제8항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 레지스터를 판독하고 레지스터에 기입하고 상기 레지스터의 필드들을 해석하기 위한 하드웨어 액세스 방법들을 생성하는 것을 포함하는 것인, 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스.
  10. 제8항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 공유 구조체의 필드들을 판독하고 공유 구조체의 필드들에 기입하는 방법들을 생성하는 것을 포함하는 것인, 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스.
  11. 제8항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 상기 하드웨어 디바이스의 상기 기계 판독가능 설명에 표현되는 하드웨어 인터페이스 엔터티들에 대한 메모리 할당기들을 생성하는 것을 포함하는 것인, 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스.
  12. 제8항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 하드웨어 인터페이스 엔티티들을 해석 및 추적하는 로그 모듈들을 생성하는 것을 포함하는 것인, 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스.
  13. 제8항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 하드웨어 인터페이스 엔터티들을 시각화하는 디버거 확장들을 생성하는 것을 포함하는 것인, 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스.
  14. 제8항에 있어서,
    상기 하드웨어 드라이버를 위해 생성된 코드는 관리 코드(managed code)로서 생성되는 것인, 하나 이상의 컴퓨터 판독가능 하드웨어 저장 디바이스.
  15. 컴퓨팅 환경에서, 하드웨어와 인터페이스하기 위해 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 시스템에 있어서,
    하나 이상의 프로세서; 및
    컴퓨터 실행가능 명령어들이 인코딩되어 있는 컴퓨터 판독가능 메모리
    를 포함하고,
    상기 컴퓨터 실행가능 명령어들은, 상기 하나 이상의 프로세서에 의한 실행 시, 상기 하나 이상의 프로세서로 하여금,
    하드웨어 드라이버가 생성될 하드웨어 디바이스의 기계 판독가능 설명 - 상기 기계 판독가능 설명은 하드웨어-소프트웨어 인터페이스 언어로 기록되고, 복수의 상이한 가능한 운영 체제 각각에 대한 하드웨어 디바이스 인터페이스를 생성하기 위해 재사용 가능함 - 을 수신하는 것;
    상기 복수의 상이한 가능한 운영 체제 각각에 대한 운영 체제 컨텍스트를 가진 코드 생성 도구를 인스턴스화하는 것;
    상기 복수의 상이한 가능한 운영 체제로부터 그리고 상기 하드웨어 드라이버가 생성되기 전에, 상기 하드웨어 드라이버가 생성되고 상기 하드웨어 디바이스가 사용될 특정 운영 체제를 결정하는 것; 및
    상기 하드웨어 디바이스에 대한 상기 하드웨어 드라이버를 위한 코드를 자동으로 생성 - 상기 생성된 코드는 상기 결정된 특정 운영 체제에 특유한 것이며 상기 결정된 특정 운영 체제에 특유한 운영 체제 인터페이스를 사용함 - 하기 위해, 상기 코드 생성 도구 및 상기 특정 운영 체제를 위한 운영 체제 컨텍스트를 사용하여 상기 기계 판독가능 설명을 처리하는 것
    을 수행하도록 구성된 코드 생성 도구를 구현하게 하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 시스템.
  16. 제15항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 레지스터를 판독하고 레지스터에 기입하고 상기 레지스터의 필드들을 해석하기 위한 하드웨어 액세스 방법들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 시스템.
  17. 제15항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 공유 구조체의 필드들을 판독하고 공유 구조체의 필드들에 기입하는 방법들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 시스템.
  18. 제15항에 있어서,
    하드웨어 드라이버를 위한 코드를 생성하는 것은, 상기 하드웨어 디바이스의 상기 기계 판독가능 설명에 표현되는 하드웨어 인터페이스 엔터티들에 대한 메모리 할당기들을 생성하는 것을 포함하는 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 시스템.
  19. 제1항에 있어서,
    상기 하드웨어 디바이스에 대한 제2 하드웨어 드라이버를 위한 제2 생성된 코드를 자동적으로 생성하기 위해 상기 코드 생성 도구 상에서 상기 기계 판독가능 설명을 처리하는 단계를 더 포함하고,
    상기 제2 생성된 코드는 상기 복수의 상이한 가능한 운영 체제 중 제2 운영 체제에 특유한 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
  20. 제19항에 있어서,
    상기 생성된 코드는 타입-비안전성 언어(type-unsafe language)이고 상기 제2 생성된 코드는 타입-안전성 언어(type-safe language)인 것인, 디바이스 드라이버에서 사용되는 코드를 자동으로 생성하는 방법.
KR1020157021046A 2013-01-04 2014-01-03 하드웨어 디바이스에 대한 소프트웨어 인터페이스 KR102104695B1 (ko)

Applications Claiming Priority (3)

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

Publications (2)

Publication Number Publication Date
KR20150104592A KR20150104592A (ko) 2015-09-15
KR102104695B1 true KR102104695B1 (ko) 2020-04-24

Family

ID=50097813

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020157021046A KR102104695B1 (ko) 2013-01-04 2014-01-03 하드웨어 디바이스에 대한 소프트웨어 인터페이스

Country Status (6)

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

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

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009031985A (ja) 2007-07-26 2009-02-12 Denso Corp ソフトウェア生成装置、および、ソフトウェア生成装置に用いるプログラム

Family Cites Families (32)

* 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
EP1238333A1 (en) * 1999-12-15 2002-09-11 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 キヤノン株式会社 デバイスドライバプログラムをカスタマイズするための情報処理装置及びデバイスドライバプログラムのカスタマイズ方法
US8713180B2 (en) 2005-06-22 2014-04-29 Cisco Technology, Inc. Zero-copy network and file offload for web and application servers
US7949766B2 (en) 2005-06-22 2011-05-24 Cisco Technology, Inc. Offload stack for network, block and file input and output
US8074231B2 (en) * 2005-10-26 2011-12-06 Microsoft Corporation Configuration of isolated extensions and device drivers
CN101297280B (zh) 2005-10-26 2013-03-27 微软公司 隔离扩展和设备驱动程序的配置
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
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

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009031985A (ja) 2007-07-26 2009-02-12 Denso Corp ソフトウェア生成装置、および、ソフトウェア生成装置に用いるプログラム

Also Published As

Publication number Publication date
WO2014107540A1 (en) 2014-07-10
US20140196004A1 (en) 2014-07-10
EP2941696A1 (en) 2015-11-11
CN105051682A (zh) 2015-11-11
CN105051682B (zh) 2018-02-23
KR20150104592A (ko) 2015-09-15
JP2016509714A (ja) 2016-03-31
US9811319B2 (en) 2017-11-07

Similar Documents

Publication Publication Date Title
KR102104695B1 (ko) 하드웨어 디바이스에 대한 소프트웨어 인터페이스
JP5122597B2 (ja) 仮想プロセッサへの直接的なインタラプトの送信
US20160371101A1 (en) Secure migratable architecture having high availability
US10977018B1 (en) Development environment for heterogeneous devices
EP2941694B1 (en) Capability based device driver framework
Madieu Linux Device Drivers Development: Develop Customized Drivers for Embedded Linux
EP2941695B1 (en) High throughput low latency user mode drivers implemented in managed code
JP2016186697A (ja) 関数間変数共有方法及び機構
Kristiansen PCIe Device Lending
Crutcher et al. Operating System
WO2023071786A1 (zh) 一种进程间的函数调用方法及相关设备
Caforio VOSySmonitoRV: a mixed-criticality solution on 64bit Linux-capable RISC-V platform
Luecke Software Development for Parallel and Multi-Core Processing
Silva Xvisor Deployment under Zynq-7000
Costa VirtIO infrastructure for a static partition hypervisor: VirtIO-Net
Danish Terrier: an embedded operating system using advanced types for safety
Verhulst et al. Requirements and Specifications for the OpenComRTOS Project
CHÁVEZ libinteractive: A Better Way to Write Interactive Tasks.
Dzikiewicz Input/Output Subsystem in Singularity Operating System
Azevedo et al. Building Platform Models with SystemC

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant