[go: up one dir, main page]

WO1999039254A2 - Architecture de logiciel servant a creer des gestionnaires de peripheriques a des niveaux bas depuis le mode utilisateur dans des systemes d'exploitation multitaches - Google Patents

Architecture de logiciel servant a creer des gestionnaires de peripheriques a des niveaux bas depuis le mode utilisateur dans des systemes d'exploitation multitaches Download PDF

Info

Publication number
WO1999039254A2
WO1999039254A2 PCT/US1999/002073 US9902073W WO9939254A2 WO 1999039254 A2 WO1999039254 A2 WO 1999039254A2 US 9902073 W US9902073 W US 9902073W WO 9939254 A2 WO9939254 A2 WO 9939254A2
Authority
WO
WIPO (PCT)
Prior art keywords
driver
device driver
user mode
mode
port
Prior art date
Application number
PCT/US1999/002073
Other languages
English (en)
Other versions
WO1999039254A3 (fr
Inventor
Richard L. Shaw
Phillip M. Adams
Jack L. Mason
Jonathan Dale Gray
Jeffery C. Bullough
Randy C. Rollins
Raymond John Feagans
Original Assignee
3Com Corporation
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 3Com Corporation filed Critical 3Com Corporation
Priority to AU25703/99A priority Critical patent/AU2570399A/en
Publication of WO1999039254A2 publication Critical patent/WO1999039254A2/fr
Publication of WO1999039254A3 publication Critical patent/WO1999039254A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver

Definitions

  • This invention relates to hardware device drivers used in an operating system. More particularly, this invention relates to hardware device drivers operating from the user mode in an operating system. 2. Present State of the Art
  • Very early modem architectures placed a communication modem external to the personal computer. Such an external placement relied upon the computer ' s interface port such as a COM port of the personal computer to interface with the modem through which data information could be exchanged.
  • the external modem contained all of the functionality necessary for performing traditional modem functions such as providing modulation and demodulation functionality for transmitted data as well as performing CODEC functionality required by the telephone network to which the modem was connected.
  • x86 architectures employ a four ring partitioning of which most operating systems utilize only two of the rings.
  • ring 0 is utilized for implementing the supervisor mode of the operating system while a ring 3 privilege level is employed for implementing a user mode.
  • a traditional communication application 10 e.g., Hyper Terminal, QuickLink, ProCom, NetScape
  • a traditional communication application 10 e.g., Hyper Terminal, QuickLink, ProCom, NetScape
  • a device driver such as Winmodem VxD device driver 16 resident within a supervisor mode interfaces to a virtual device driver such as VCOMM 14 and hardware such as hardware 18 which may take the form of a modem or other communication-type device and may further include video type devices.
  • supervisor mode portion of the operating system when such behavior renders the user mode application inoperable.
  • software vendors generate portions of the software for inclusion within the kernel mode, there are additional and even onerous design requirements placed upon the software vendor.
  • Such guidelines often inflict limitations on what a supervisor mode component of software may perform.
  • such restrictive guidelines also render supervisor mode software very difficult to maintain due to the restriction and limitations of the functionality that may be performed.
  • One exemplary limitation for performing such functionality in the kernel mode is inherent in the architecture of x86 processors. For example, supervisor mode code utilizing features of the x86 architecture such as the floating point processor or the MMX processor are not fully reconstructed when context switching occurs.
  • the context or register values and other information such as stack pointers are preserved during a switch, thus enabling a process to resume a specific execution thread by reinstalling the register and other flag values when returning to the process.
  • the floating point values and the MMX values are not preserved as part of a typical context switch task. Therefore, supervisor mode components utilizing these features become volatile when values in the floating point unit and MMX process are not preserved. While many supervisor mode components require sophisticated processing such as that capable of being performed by a floating point processor, instability of the operating system is extremely common.
  • the present invention provides an architecture having a thin layer supervisor mode driver that appears to a standard user application as a device driver capable of servicing hardware directly from the supervisor mode.
  • the present invention further comprises a routing driver component coupled to the thin layer device driver to communication with a device driver wrapper that provides a "supervisor mode-like" environment for a device driver.
  • device drivers may be extracted from their supervisor mode linkage and relinked to the device driver wrapper without requiring recoding as is customary when porting software modules. Furthermore, a device driver may be reused between platforms once a device driver wrapper exists for each platform with the reusability of a device driver across multiple platforms being capable of being extended to a family of standard products that are interchangeable across platforms.
  • Figure 1 is a simplified architectural diagram of traditional communication modules and their operational locations, in accordance with prior art implementations;
  • Figure 2 is a simplified architectural diagram of the components and relationships for providing low level hardware drivers from the user mode, in accordance with the preferred embodiment of the present invention;
  • FIG. 3 is a more detailed description of the functional interfaces between the various components for facilitating the relocation of a device driver to the user mode of an operating system, in accordance with the preferred embodiment of the present invention
  • Figure 4 is a simplified depiction of functionality incorporated within the user mode to facilitate the placement of a device driver in the user mode of a partitioned operating system, in accordance with the preferred embodiment of the present invention
  • Figure 5 is a simplified diagram of supervisor mode support drivers employed to facilitate the operation of a device driver in user mode, in accordance with the preferred embodiment of the present invention
  • FIG. 6 is a simplified block diagram of the components and relationships for providing low level hardware drivers from the user mode in a Windows NT, in accordance with an alternate embodiment of the present invention
  • Figure 7 is a simplified depiction of functionality incorporated within the user mode to facilitate the placement of a device driver in the user mode of a Windows NT operating system, in accordance with an alternate embodiment of the present invention
  • Figure 8 is a simplified diagram of supervisor mode support drivers employed to facilitate the operation of a device driver in user mode in an embodiment employing a
  • the present invention embodies within its scope both methods and an apparatus for enabling a user mode device driver to interact directly with an I/O port or hardware device without requiring the direct services of the supervisor mode.
  • the present invention also provides a method and apparatus for placing traditional supervisor mode drivers in the user mode portion of the operating system thereby enabling the operating system to terminate a wayward user mode device driver without causing the entire operating system to seize with a supervisor mode device driver exhibits aberrant behavior.
  • Figure 2 is a simplified block diagram of the architecture employing a thin supervisor mode system interface to portray to the operating system a compatible interface while routing commands and data to a device driver located in the user mode for executing and interacting directly with an I/O port or hardware without intermediary involvement by the supervisor mode.
  • the present invention allows the operating system to see the system interface connections that are expected in the supervisor mode, while performing only minimal work in supervisor mode and placing the majority of functionality in the user mode where they are far less likely to cause catastrophic volatility to the operating system when problems occur in a device driver.
  • user mode applications include E-mail, word processing, and graphical programs such as games.
  • the user mode cannot communicate directly with an I/O port or hardware.
  • the user mode traditionally is restricted in the functions and processes that it can request the system to perform. For instance, one user application is prevented from interacting or interfering with the operation of another user application.
  • the operating system in user mode attempts to keep each user application isolated to prevent them from being improperly behaved and incurring a negative impact on other user applications.
  • Supervisor mode 28 is the portion of the architecture where the operating system kernal resides.
  • the incorporation of supervisor mode software modules such as device drivers extends the operating system, thus enabling it to perform additional specific functions.
  • Typical supervisor mode functionality specifically includes interacting with I/O ports and hardware (e.g., video display, hard drive, CD ROM drive and floppy drive).
  • software modules can see all memory, I/O, interrupts and has access to all other components.
  • user mode 26 has no such exposure or control.
  • a user application 30 generally operates in user mode 26, however, user application 30 needs the services that the operating system provides in the supervisor mode, and therefore, execution of user application 30 must cross between user mode 26 and supervisor mode 28 to obtain some of those services.
  • user application 30 really can't perform rudimentary functionality such as obtaining a file off of the disk or storing information to a disk without the services of supervisor mode 28.
  • APIs 32 provide fundamental command interface capable of passing the appropriate information and getting the operating system or the driver which is an extension of the operating system in supervisor mode 28 to take that action.
  • user application 30 may request to open a file named ABC.PPT, which is essentially performed by putting in a command with the data that is affiliated with that command followed by the issuance of the specific API.
  • the specific API is comprised of a certain number of predefined parameters that it needs. Therefore, if a block of data is targeted for storage, then one of the parameters for that API is a pointer to the data.
  • a device driver would reside in the supervisor mode, either a standard device driver or a custom device driver for a specific type of I/O port or hardware and carries out the specific data processing and appropriate control of the hardware as necessary.
  • the supervisor portion, system interface driver 34 and device router driver 44 are much thinner and leaner with the majority of the functionality located in the user mode portion of the invention.
  • the supervisor mode portion basically presents the minimal interface entry points that the particular function requires by the operating systems. Basic operating system functionality and compatibility dictate the a particular kind of device must present a certain interface to the operating system defining the specifics for interacting with the operating system.
  • system interface driver 34 provides a thin driver interface to provide the specific set of entry points for the driver that the operating system requires. None of the device driver functionality is performed in the supervisor mode, although the operating system and user application perceive it as being consistent with the more traditional supervisor mode location of the device driver.
  • user application 30 calls in with an API to the operating system with a device name (e.g., Coml, Com2) that the operating system recognizes.
  • User application 30 calls through API 32 which in turn determines that, for example,
  • System interface driver 34 is further comprised of at least one base class 36 which defines a unique requirement for how- interface driver 34 "hooks" to the operating system with the respective entry points for use by the operating system when interacting.
  • base class 36 would be referring to a disk driver base class that provides insight and understanding about the functionality the operating system will need to employ (i.e., it will need to perform functions such as open driver, driver reads, driver writes, driver status, etc.).
  • each kind of device driver will have unique types of commands that will be received from the operating system, therefore, each kind of driver will need a unique base class connection to make the architecture function properly.
  • base class 36 is implemented in the Microsoft® Windows NT 4.0 operating system under the name of a port class and employs approximately 21 specific actions that the operating system is going to expect the driver to perform for proper interaction (e.g., understanding of data structures, command structures) and the work that is required out of each one through the architecture to actually get the work done.
  • a generic base class is defined as opposed to defining base class 36 as, for example, a SCSI or IDE class.
  • a call comes from user application 30, for example, to open a device
  • the call comes through API 32 through the operating system into system interface driver 34.
  • the architecture Prior to the call for a specific service, the architecture passes through an initialization phase wherein the operating system is booting or instantiating itself the first time.
  • an operating system registry 38 is consulted, for example, to determine how many device drivers are needed for a session.
  • the operating system instantiates an instance of the necessary interfaces and the links to device router 44 based on that information in operating system registry 38.
  • a configuration program 42 is executed as the operating system boots.
  • Configuration program 42 contains sufficient knowledge about the operating system registry 38, the operating system itself and potential hardware or devices or device drivers that could be used in the system.
  • Configuration program 42 also contains functionality to determine through operating system registry 38 the presence of devices for the session or devices that have been recently inserted, which is yet further notified through an operating system configuration manager 40, when, for example, a PCMCIA card or a
  • Operating system configuration manager 40 recognizes that the new device has been inserted, works with the operating system in supervisor mode to determine who is intended to support that device using an identification string that identifies each hardware piece in operating system registry 38 once the device is initially installed.
  • configuration program 42 in user mode 26 establishes a connection between itself and operating system configuration manager 40.
  • operating system configuration manager 40 When the device is recognized by operating system configuration manager 40, operating system configuration manager 40 calls through interface 52 into user mode 26 and notifies configuration program 42 that a device is present.
  • configuration program 42 identifies the device, works through operating system registry 38 to store information regarding the settings to use for the hardware, driver or drivers for that session, writes that information into operating system registry 38 and sends a message 43 to a device driver wrapper 46 to notify the architecture that a new device is present requesting support.
  • Device driver wrapper 46 then sends a message through interface 56 to go from user mode 26 down to device router driver 44 stating that a new device is present and the location where information about the new device is located in operating system registry 38. Therefore, once configuration program 42 has stored the information in operating system registry 38 and sends the message to device driver wrapper 46, the functionality of configuration program 42 is complete.
  • Device driver wrapper 46 sends a message to device router driver 44 which then instantiates the appropriate handlers 60, 66 and 68 and device router driver 44 then sends a message to system interface driver 34 for notification that an additional instantiation is needed.
  • Both system interface driver 34 and device router driver 44 read the information stored in operating system registry 38 by configuration program 42 and configure themselves accordingly to allocate system resources such as memory or IO space, interrupts and other services that are only feasibly performed by a device driver in supervisor mode. Such "supervisor mode-only" services are then set up by system interface driver 34.
  • base class 36 that is configured to the parameters that the operating system deduced in conjunction with operating system configuration manager 40 and configuration program 42 are complete.
  • device driver wrapper 46 loads device driver 48 for use by the particular target device such as an I/O port or hardware. That is to say, device driver wrapper 46 loads device driver 48 and then instantiates all the remaining threads that constitute the rest of interface or threads 56. Following the loading of device driver 48 by device driver wrapper 46, device driver wrapper 46 makes the connection through threads 56 to device router driver 44 and device router driver 44 reads operating system registry 38 and instantiates a link name 62 which is a unique link name for every device supported and a unique driver name for every driver to be supported.
  • this provides a method wherein a port open command comes in from user application 30 and system interface driver 34 knows through operating system registry 38 that COMl is really COMm calling down from user mode 26 into supervisor mode 28 ending up in system interface driver 34 and instantiating one of base classes 36 thereby behaving similar to an alias for COMl .
  • one user application 30 decides to operate as COM3 to system interface driver 34' but is known as COMSMDevice 0 in one instance.
  • device router driver 44" from operating system registry 38 knows that in this particular case system interface driver 34" is to behave as a regular modem and that is, for example, link driver_0 in device router driver 44". Therefore, it knows to send the calls through threads 56".
  • system interface driver 34 still presents itself as COM3 and is known in the system as COM3 but now operates with device router driver 44" to link to driver l instead of driver_0.
  • Linking to driver_l operates through another interface of threads 56'" to device driver wrapper for driver l instead of driver_0. Therefore, a device driver wrapper is present for each device driver and also a set of threads 56 exists between device router driver 44" and each device driver wrapper.
  • link driver objects 60,66 and 68 can steer routing from one to the other and when device driver_0 48 is hooked to link driver 60 which could be a standard modem and device driver_l 72 with its wrapper 70 at user mode with its set of threads like 56 could be working through link driver 66 and be a GSM file and by simply changing the information in the registry through an application or an applet, as known by some operating systems, different functionality may be created through the same virtual pipe through the system.
  • the hardware remains the same, the user application remains the same but internally to the architecture of the present invention, it is routed differently to a different device driver running in ring 3 to achieve a different result.
  • Thread 54 is a single thread between system interface driver 34 and device router driver 44. Thread 54 is a single thread per device that is being supported. Therefore, if there is one device driver or one hardware device or I/O port, then there will be one thread 54. This single thread provides a single entry point where a command or a value that directs, for example, an interrupt request, an open or a close, a read or a write or a status. Therefore, interface 90 which in one embodiment employs an internal IOCTL command common to Microsoft® operating systems is changed depending upon the number of things that need to be performed which is influenced by the kind of driver being supported by the architecture.
  • Thread 54 is created in the operating system when system interface driver 34 instantiates itself. Threads 56 between device router driver 44 and individual device driver wrappers 46, 70 and 74 are individual threads: interrupt, device open, device close, device read, device write and device get status are all unique threads. Figure 5 is a diagram of a single device instance. If there are multiple devices then there would be multiple instances of each of these. It should be reiterated that in Figure 3, thread 54 and threads 56 are not symmetrical. In thread 54, one thread performs all of the functionality depending on which function is requested. For example, suppose the user application has requested an open command. A thread is created in the operating system between system interface driver 34 and device router driver 44.
  • System interface driver 34 calls into the device 10 control entry point at device router driver 44 with thread 54 which is basically a request to have the operation performed.
  • Device router driver 44 pends thread 54 and since it is the only thread that is between the two devices, no other calls from the operating system or user application can come through until that one is completed.
  • Device router driver 44 then takes the information from the device 10 control call and that pended thread 54 and completes device router driver's 44 request via threads 56 DeviceOpen thread for that device to which the command was directed.
  • a simplified description suffices to state that the DeviceOpen thread to the device driver, runs in device driver wrapper 46 and device driver 48 to perform all the necessary functionality to open the device or I/O port.
  • device driver wrapper 46 issues to device router driver 44 on that same device open thread asking it to run that one again and device router driver 44 pends that thread, that, and we'll talk about the rest of that here in a moment.
  • thread 54 when it is not performing is complete and therefore not executing.
  • device driver wrapper 46 first instantiates, it links itself to device router driver 44 by establishing all the threads that comprise threads 56 and by calling through using the device 10 control, for example, from user mode 26 to supervisor mode 28 and in the exemplary case of a communication (COM) device, 23 individual threads per device get instantiated between device driver wrapper 46 and device router driver 44.
  • COM communication
  • each thread is received and pended by device router driver 44 which means that once the components of the present invention are initialized and the user application is yet to issue requests, thread 54 between system interface driver 34 and device router driver 44 is complete and not functioning, while all of the 23 threads of threads 56 from device router driver 44 in supervisor mode 28 to device driver wrapper 46 located in user mode 26 are pended. Pending threads provides performance enhancement since if one were to simply call from user mode 26 from an application down to supervisor mode 28, a context switch would be required every time, which as those skilled in the art appreciate, requires substantial time to perform due to the delay in storing register and pointer values and loading other register and pointer values.
  • a second problem also occurs in that every time one crosses the boundary between user mode and supervisor mode, the operating system takes that opportunity to service any pending high priority events. Because device drivers need to operate in substantially real time, the introduction of significant delays introduced between calls becomes unacceptable. Therefore, by initiating and pending the individual threads of threads 56 performance is greatly enhanced by foregoing context switching. Those skilled in the art appreciate the setting of a thread to "complete” starts the thread executing again and a mode transition and hence a context switch is not necessary. Additionally, context switching between modes introduces problems inherent in the x86 architecture in that co-processor registers are not preserved. By placing the device driver in user mode, the operating system processes the switching, for example in multitasking, and therefore forgoes the x86 shortcomings.
  • Figure 4 depicts the composition of the device driver and the components of the device driver wrapper, in accordance with the preferred embodiment of the present invention.
  • Prior discussion relating to device driver wrapper 46 have depicted it as a monolithic entity when in the preferred embodiment of the present invention, device driver wrapper 46 is more incitefully depicted as a composition of functional modules which greatly enhance the reusability and minimize the quantum of code that must be customized between implementations on various hardware and operating system platforms.
  • Device driver wrapper 46 may also be viewed as a frame or component that facilitates the relocation of a device driver from the supervisor mode to the user mode with minimal alterations to the device driver.
  • the architecture of the present invention is depicted such that the device driver originating in a supervisor mode may be relinked with device driver wrapper 46 and as far as device driver 48 knows, it is still operating as usual.
  • Component 86 functions as a driver interface API to user mode API emulation/real time emulation applications. As device driver 48 is concerned, it perceives itself as operating in supervisor mode. What the present invention has done is to put a wrapper around device driver 48 and enabled it to continue to operate as it was originally designed. I n order to provide such an environment for device driver 48, component 86 provides a real time emulation that is created using standard operating system calls and functions to emulate that environment for device driver 48.
  • component 114 provides an operating system for user mode API set which is basically the standard operating system for user mode APIs.
  • component 86 is illustrated above component 1 14 because of the API expanding effect of component 86.
  • Device driver wrapper 46 provides all of the interfaces required by device driver 48 when operative in the supervisor mode and facilitates the extraction of a device driver previously designed to operate in supervisor mode and the subsequent placement of the device driver into the user mode by plugging the device driver into the device driver wrapper.
  • device driver wrapper 46 emulates as far as device driver 48 is concerned a system interface layer in supervisor mode. Therefore, as far as device driver 48 is concerned, it has hooked itself just like it does in supervisor mode to that system interface layer for its specific functionality. For a COM driver that would be VCOMM in a Microsoft operating system. So as far as the device driver is concerned, it perceives that it has connected itself to VCOMM when in reality it has connected itself to the device driver wrapper. Because of this emulated environment provided by device driver wrapper 46, device driver 48 may be utilized in its entirety without stripping or reworking portions of the device driver. In the preferred embodiment of the present invention, component 114 is part of the operating system while component 86 could alternatively be merged with device driver wrapper 46.
  • Figure 5 is a simplified block diagram of the architecture for multiple user applications interfacing with multiple device drivers. Multiple instances of thread 54 are depicted by thread 55 and 61. Likewise, device router driver 44' illustrates multiple device driver base classes 60, 66 and 68 while system interface driver 34' illustrates multiple driver base classes as well. Figure 5 further illustrates that each device has its own interrupt, unique port addresses and separate read and write data cues and threads. Figure 6 depicts a simplified block diagram for implementing the present invention in a Microsoft NT® 4.x and WinModem architecture environment using functions and terminology consistent therewith. Therefore, instead of being a generic user application 30, a COM application would be created using NT specific definitions such as a port class rather than a base class. Additionally, in Figure 6, the device driver is designed to integrate into VCOMM or unimodem.
  • FIG. 7 is a simplified block diagram of an implementation of the present invention within a Microsoft NT 4.0 operating system environment, in accordance with the preferred embodiment of the present invention.
  • a series of modular protocol modules are presented which include functionality such as fax, DTE, v.42, v.80, etc. which may be reused across multiple platforms.
  • the present architecture provides a partitioned structure such that reuse is maximized requiring only the minimal amount of code to be rewritten when porting or upgrading operating systems.
  • Device driver 48' is depicted as being taken from a supervisor role, which while not a requirement, certainly enhances the reusability of legacy drivers.
  • device driver wrapper 46' provides a Win32 compatible API environment for device driver 48'.
  • One of the few portions of the user mode driver created by the architecture of the present invention is the hardware specific interfacing portion for directly controlling the hardware.
  • the SDPI DRV represents that portion of the code that is specific to unique hardware.
  • STPI DRV is an API chosen to adopt into a WinModem and soft modem implementations but a LAN driver would not have one of those.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Procédé et architecture servant à créer une interface avec un gestionnaire de périphérique à des niveaux bas dans la partie mode utilisateur d'un système d'exploitation possédant au moins un mode utilisateur et un mode superviseur. Cette architecture comprend un gestionnaire d'interface du système en mode superviseur à couche mince servant à présenter une interface complète à une application d'utilisation au moyen dudit gestionnaire de périphérique de niveau bas afin d'exécuter les commandes de l'utilisateur. Cette architecture possède, de plus, une partie gestionnaire d'acheminement de périphérique située également dans la partie superviseur du système d'exploitation afin d'effectuer un acheminement entre le gestionnaire d'interface de système en mode superviseur à couche mince et le gestionnaire de périphérique situé dans la partie mode utilisateur du système d'exploitation. Ces gestionnaires de périphériques ne nécessitent normalement pratiquement aucune modification, étant donné qu'un dispositif de bouclage de gestionnaire de périphérique émule un environnement API pour le gestionnaire de périphérique. Ce dispositif de bouclage facilite son recoupage avec le gestionnaire de périphérique sans nécessité de recodage.
PCT/US1999/002073 1998-01-30 1999-01-29 Architecture de logiciel servant a creer des gestionnaires de peripheriques a des niveaux bas depuis le mode utilisateur dans des systemes d'exploitation multitaches WO1999039254A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU25703/99A AU2570399A (en) 1998-01-30 1999-01-29 Software architecture for providing low level hardware device drivers from the user mode under multi-tasking operating systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US1556698A 1998-01-30 1998-01-30
US09/015,566 1998-01-30

Publications (2)

Publication Number Publication Date
WO1999039254A2 true WO1999039254A2 (fr) 1999-08-05
WO1999039254A3 WO1999039254A3 (fr) 1999-10-07

Family

ID=21772171

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/002073 WO1999039254A2 (fr) 1998-01-30 1999-01-29 Architecture de logiciel servant a creer des gestionnaires de peripheriques a des niveaux bas depuis le mode utilisateur dans des systemes d'exploitation multitaches

Country Status (2)

Country Link
AU (1) AU2570399A (fr)
WO (1) WO1999039254A2 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1282037A1 (fr) * 2001-08-03 2003-02-05 Drecq Daniel Technologies D 2 T Programme informatique de pilotage d'interface en temps réel
EP1281948A1 (fr) * 2001-08-03 2003-02-05 Drecq Daniel Technologies D 2 T Programme informatique de contrôle et de commande pour banc d'essai
WO2004001615A1 (fr) * 2002-06-19 2003-12-31 Telefonaktiebolaget Lm Ericsson Architecture de logiciel pilote de reseau
US6871350B2 (en) * 1998-12-15 2005-03-22 Microsoft Corporation User mode device driver interface for translating source code from the user mode device driver to be executed in the kernel mode or user mode
EP1591891A2 (fr) 2004-04-29 2005-11-02 Microsoft Corporation Pilotes USB génériques
EP1603038A2 (fr) 2004-05-14 2005-12-07 Microsoft Corporation Fonctionnalité prête-à-l'emploi pour des dispositifs non-supportés
WO2009076671A3 (fr) * 2007-12-13 2009-07-30 Advanced Micro Devices Inc Architecture à plusieurs sous-systèmes de pilotes d'ordinateurs à modes de réduction de consommation, et logiciels et méthodes associées
WO2014193443A1 (fr) * 2013-05-31 2014-12-04 Microsoft Corporation Exécutions de pilotes dans une sandbox en mode utilisateur sur une plateforme de pilotes limitée
US9256440B1 (en) * 2009-03-30 2016-02-09 Amazon Technologies, Inc. Facilitating device driver interactions

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5129083A (en) * 1989-06-29 1992-07-07 Digital Equipment Corporation Conditional object creating system having different object pointers for accessing a set of data structure objects
DE69110908T2 (de) * 1991-04-01 1996-02-08 Cray Research Inc Auffangen eines priviligierten befehlswortes zur kontrolle eines betriebssystems.
EP0610677A3 (fr) * 1993-02-12 1995-08-02 Ibm Module de gestion de périphérique de communication fonctionnant en deux modes.
US5784615A (en) * 1994-12-13 1998-07-21 Microsoft Corporation Computer system messaging architecture
US5727212A (en) * 1995-04-12 1998-03-10 International Business Machines Corporation Object oriented device driver system for procedural device drivers

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6871350B2 (en) * 1998-12-15 2005-03-22 Microsoft Corporation User mode device driver interface for translating source code from the user mode device driver to be executed in the kernel mode or user mode
US7644413B2 (en) 1998-12-15 2010-01-05 Microsoft Corporation User mode device driver interface
EP1282037A1 (fr) * 2001-08-03 2003-02-05 Drecq Daniel Technologies D 2 T Programme informatique de pilotage d'interface en temps réel
WO2003014922A3 (fr) * 2001-08-03 2004-02-26 Drecq Daniel Technologies D 2 Programme informatique de pilotage d'interface en temps reel
EP1281948A1 (fr) * 2001-08-03 2003-02-05 Drecq Daniel Technologies D 2 T Programme informatique de contrôle et de commande pour banc d'essai
WO2004001615A1 (fr) * 2002-06-19 2003-12-31 Telefonaktiebolaget Lm Ericsson Architecture de logiciel pilote de reseau
CN1647054B (zh) * 2002-06-19 2010-09-08 艾利森电话股份有限公司 双模网络设备驱动设备、系统和方法
US8332875B2 (en) 2002-06-19 2012-12-11 Telefonaktiebolaget Lm Ericsson (Publ) Network device driver architecture
US7451456B2 (en) 2002-06-19 2008-11-11 Telefonaktiebolaget L M Ericsson (Publ) Network device driver architecture
EP1591891A2 (fr) 2004-04-29 2005-11-02 Microsoft Corporation Pilotes USB génériques
EP1591891A3 (fr) * 2004-04-29 2007-11-21 Microsoft Corporation Pilotes USB génériques
US7802022B2 (en) 2004-04-29 2010-09-21 Microsoft Corporation Generic USB drivers
US7577765B2 (en) 2004-04-29 2009-08-18 Microsoft Corporation Advanced power management in generic USB drivers
US7650436B2 (en) 2004-04-29 2010-01-19 Microsoft Corporation I/O handling in generic USB drivers
EP1603038A2 (fr) 2004-05-14 2005-12-07 Microsoft Corporation Fonctionnalité prête-à-l'emploi pour des dispositifs non-supportés
EP1603038A3 (fr) * 2004-05-14 2008-03-05 Microsoft Corporation Fonctionnalité prête-à-l'emploi pour des dispositifs non-supportés
WO2009076671A3 (fr) * 2007-12-13 2009-07-30 Advanced Micro Devices Inc Architecture à plusieurs sous-systèmes de pilotes d'ordinateurs à modes de réduction de consommation, et logiciels et méthodes associées
US8487943B2 (en) 2007-12-13 2013-07-16 Advanced Micro Devices, Inc. Driver architecture for computing device having multiple graphics subsystems, reduced power consumption modes, software and methods
CN101978352B (zh) * 2007-12-13 2017-11-03 先进微装置公司 用于具有多重图形子系统、减少的功率消耗模式的计算装置的驱动程序架构、软件和方法
US9256440B1 (en) * 2009-03-30 2016-02-09 Amazon Technologies, Inc. Facilitating device driver interactions
US20160124759A1 (en) * 2009-03-30 2016-05-05 Amazon Technologies, Inc. Facilitating device driver interactions
US10198277B2 (en) 2009-03-30 2019-02-05 Amazon Technologies, Inc. Facilitating device driver interactions
WO2014193443A1 (fr) * 2013-05-31 2014-12-04 Microsoft Corporation Exécutions de pilotes dans une sandbox en mode utilisateur sur une plateforme de pilotes limitée
US9075985B2 (en) 2013-05-31 2015-07-07 Microsoft Technology Licensing, Llc Restricted transmogrifying driver platform
KR20160015300A (ko) * 2013-05-31 2016-02-12 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 사용자 모드에서의 샌드박스 내의 제한된 드라이버 플랫폼의 드라이버 구동
RU2646332C2 (ru) * 2013-05-31 2018-03-02 МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи Ограниченная платформа драйверов, которая запускает драйверы в песочнице в пользовательском режиме
KR102089826B1 (ko) 2013-05-31 2020-05-27 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 사용자 모드에서의 샌드박스 내의 제한된 드라이버 플랫폼의 드라이버 구동

Also Published As

Publication number Publication date
AU2570399A (en) 1999-08-16
WO1999039254A3 (fr) 1999-10-07

Similar Documents

Publication Publication Date Title
US6128731A (en) Advanced boot sequence for an +86 computer system that maintains expansion card device compatibility
RU2327208C2 (ru) Модель драйвера, не зависимого от режима обработки
KR100961349B1 (ko) Ｖｅｘ - 가상 확장물을 고립시키는 방법
US6199181B1 (en) Method and system for maintaining restricted operating environments for application programs or operating systems
CA2231937C (fr) Extension dynamique de pilotes de peripheriques statiques
US4787026A (en) Method to manage coprocessor in a virtual memory virtual machine data processing system
US5964843A (en) System for enhancing device drivers
US5812820A (en) Virtual UART
JP4903257B2 (ja) セキュアなオペレーティングシステムのスイッチング
EP1548589B1 (fr) Systèmes et méthodes pour la virtualisation d'un dispositif bimodal de dispositifs matériels réels et idéalisés
US7434224B2 (en) Plural operating systems having interrupts for all operating systems processed by the highest priority operating system
US5784549A (en) Reduced or fail-safe bootstrapping of a system having a graphical user interface
EP2479666B1 (fr) Procédés et systèmes pour afficher les graphiques de plateforme au cours de l'initialisation du système d'exploitation
KR20060047639A (ko) 가상 환경으로부터 하드웨어로의 직접적인 액세스를제공하는 컴퓨터 판독가능 매체
US5937185A (en) Method and system for device virtualization based on an interrupt request in a DOS-based environment
US6357003B1 (en) Advanced firmware boot sequence x86 computer system that maintains legacy hardware and software compatibility
WO1999039254A2 (fr) Architecture de logiciel servant a creer des gestionnaires de peripheriques a des niveaux bas depuis le mode utilisateur dans des systemes d'exploitation multitaches
EP1616257B1 (fr) Systemes d'exploitation
EP4187387A1 (fr) Procédé et appareil de communication inter-processus et support de stockage informatique
US5790837A (en) Method and system for device virtualization based on an interrupt request in a dos-based environment
WO2020183121A1 (fr) Appareil pour transmettre une requête à médiation à un circuit de traitement en réponse à une requête de configuration
Clarke et al. Dynamic Memory Model Reconfiguration in DEIMOS
CA2524455A1 (fr) Systeme et procede de virtualisation du bios et de ses services de temps d'execution
HK1058982B (en) Process-mode independent driver model

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AU CA JP

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AU CA JP

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

122 Ep: pct application non-entry in european phase