JP2003521027A - An abstract device driver model for device driver portability across different operating system platforms - Google Patents

Abstract

Abstract: An abstract interface model for set-top terminal device drivers, such as for use in cable or satellite television subscriber networks. In a layered software architecture, the device driver's abstract interface enables communication between the client and the device driver, regardless of the operating system (OS) on which the device driver runs. In a first embodiment, the architecture includes a dedicated (OS-specific) device driver interface, and the proxy translates the interface service request from the client into an OS-specific call to the device driver. To do this, we use the first abstract interface. For clients that directly access the dedicated (OS-specific) device driver interface, the second abstract interface is used to translate the interface's service request into an OS-specific call to the device driver. Is done. The OS has direct access to the specific device driver interface thus maintained. In the second example, the architecture does not include a dedicated (OS-specific) device driver interface. Therefore, the device driver core control uses only the first abstract interface to translate the service request of the interface from the client to the device driver into a specific call to the device driver. Looks to interface directly with core control.

Description

Detailed Description of the Invention

The present invention relates to the field of digital set-top software / firmware for use in eg cable or satellite television subscriber networks. In particular, the abstract interface model will be provided to the device driver of the set top terminal.

The recent advent of digital set top terminals has stimulated the growth of subscriber television networks such as cable / satellite television networks. Such terminals can support increased levels of programming services and applications and features based on various software, such as electronic program guides, stock or weather finds, home shops and banks. Moreover, this trend is expected to continue with the convergence of telephone, television and computer networks, and the growth of in-home computer networks.

Each terminal is a different hardware device, eg a tuner, demodulator, MPEG-2 decoder (eg audio, video and data), video encoder, audio mixer etc. (controlled by an individual divider). including.

Furthermore, each terminal uses an operating system (OS) platform for controlling the functions of the terminal. The OS has a hierarchical structure, but here the functions are separated according to the abstraction level. At the bottom of the structure, the lowest abstract level or layer is the hardware device level. The next highest level is the device driver level. At the top of the structure, the highest abstract level is typically the client level. In addition, each level manages a set of objects (which can be hardware or software objects) and defines the operations that can be performed on the objects.

However, for convenience, device drivers are required that are run individually for each operating system platform, eg, for different set top manufacturers or for different set tops from the same manufacturer. is there.
Moreover, one hardware platform will be needed to support different OS platforms. It is even possible for different terminals on the same network to have different operating systems.

In general, continuous operating system changes in set-top terminals are the result of improvements, cost reductions, new elements, and secondary supply manufacturers. This is problematic because terminal manufacturers must write different device drivers for different operating systems on different networks, even if each network typically uses one OS platform. . Device drivers for one network OS cannot be easily transferred to another OS in another network.

The need to develop and deliver the latest device driver software / firmware to the terminal brings additional spending to terminal manufacturers and network providers.

In particular, device drivers for a particular OS are tightly bundled with the OS, which means that each driver will have certain details about the OS through the execution of the driver, and thus a complete development cycle. ， It means that it is required to develop a driver for each OS platform.

[0009] These problems are exacerbated by the continuous improvement and replacement of the terminals of the network as technology advances.

Therefore, under different set top operating systems,
It is desired to provide a device driver abstract interface modem that allows the development of a set of device driver code and device user code to execute. The interface should allow the device driver to be executed only once and be useful under some operating and set-top platforms. One such suitable platform is the DCT5000 series of terminals manufactured by the assignee, General Instruments Corporation.

The interface should enable bidirectional communication between the device drive and the client.

The interface ensures that the hardware device looks the same to the client of the terminal (eg, to which an application or other entity is communicating), regardless of the OS on which the hardware device operates. Should. Similarly, the client needs to look the same to the actual device driver, regardless of operating system.

The interface should allow sharing architecture and code across both OS and hardware platforms.

The interface must be available with or without a dedicated (operating system specific) device driver interface.

The interface must be implemented using an object oriented or procedural programming language.

The present invention provides a device driver abstraction with the above and other advantages.
Provides an interface model.

SUMMARY OF THE INVENTION The present invention relates to an abstract interface model for device drivers for set top terminals.

The present invention enables the development of driver core logic only once. Each core
Needs to be translated separately for the OS platform.

In a particular embodiment, a method is provided for enabling communication between a device driver of a terminal and a client, wherein the terminal has a particular operating system with which the device driver operates. There is.
The method comprises providing a first abstract interface for converting a service request from a client having an operating system independent format into a call to a device driver having a format compatible with a particular operating system. Including.

In particular, the first abstract interface is any one of a number of different formats compatible with a number of corresponding different operating systems,
Adapted to provide calls to device drivers.

If a dedicated (OS specific) device driver interface exists,
The device driver interface is adapted to receive direct, secondary calls from other clients that have a format compatible with the particular operating system. The second call does not go through the first abstract interface. In addition, the device driver interface provides a second call to the device driver via the second abstract interface.

A related method for enabling communication between a client and a device driver (where the terminal has a specific operating system associated with which the device driver operates) is a specific operating system format, Providing a first abstract interface for converting a message from a device driver into a corresponding message in an operating system independent format for use by a client.

The first abstract interface translates the message from any one of a plurality of different formats compatible with a corresponding plurality of different operating systems into an operating system independent format for use by a client. Is adapted for.

[0024]   A corresponding device is provided.

The present invention relates to an abstract interface model for a device driver of a set top terminal.

Known object-oriented design techniques provide a way to form objects abstractly. Primarily, designers can
You can create an object that provides an abstract interface.
This happens dynamically during software execution time.

The present invention extends or modifies this idea as follows. A unique driver interface is created for all operating systems. This is done each time the source coat is translated and only happens once (statically).

Therefore, when a new OS platform is developed, at most, it is required to develop a proxy, an OS specific driver, and an OS specific driver support. This typically represents less than about 10% of the driver's development cycle, which saves significant cost and time.

In particular, all of the device driver logic is located or executed in device driver core control. This module or subsystem resides just above the hardware device level and communicates directly with the hardware device or with the OS, with the assistance of specific driver assistance subsystems. The core control contains most of all the code for this architecture.

The device driver core control executes the logic defined in the device driver abstract interface. The core control contains all the code needed to provide these services.

FIG. 1 illustrates an abstract interface model of a device driver for use with an OS having a dedicated device driver interface according to the present invention. The dedicated device driver interface 130 may be, for example, Microsoft (registered trademark) Windows CE.

The layered device driver model 100 has multiple levels 110, 120, 130, 14
Includes 0, 150 and 160. Typically, the OS, at one level, just contains the drivers that are run in the interface. The lowest level 160 (the lowest abstract level) is the set top terminal, the hardware device itself
Including 162.

The next abstract level 150 includes a second device driver abstract interface 152, a device driver core control 154, and an OS-specific driver assistance 156. The next abstract level 140 includes OS specific device driver execution 142. The next abstract level 130 includes an OS device driver interface 132.

The next abstract level 120 includes a first device driver abstract interface 132 and a device driver proxy 124.

The next abstract level 110 (highest level) includes a client 112 that uses the device driver abstract interface 122 and a client 114 that uses the OS device driver interface 132.

Although only one device is shown, it should be noted that the present invention is suitable for use with a variety of set top devices.

In the architecture of FIG. 1, the OS-specific device driver 142 uses the second device driver abstract interface 152 to
Controls or drives the device driver core control 154. In particular, the OS has a specific device driver 142, this level 140 allows the OS to call a specific device driver (specifically tied to the OS) and call an abstract device driver defined by the device driver abstract interface 152. Convert or change to.

The OS itself calls a service in a specific device driver 142 through the interface 132 of the driver defined by the operating system. The OS may be, for example, Microsoft (registered trademark) Windows CE.
This OS has the format "xxx" in the Windows CE device driver. Invokes a call with "IOCTL", where "xxx" indicates the device's Windows CE.

Regarding driver invocation, Windows CE shows an example of invoking a "DeviceIoControl" invocation, where the proxy passes through the device with the Win CE name.

The device driver proxy 124 is an abstract interface 122.
Represent the device driver 154 to the client using (which is functionally the same as the device driver abstract interface implemented by the device driver core control 154). These clients may include, for example, middleware and applications. Therefore, the client appears to interface to the driver core itself. In addition, the proxy 124 translates or modifies interface service requests from the clients 112 to their associated OS specific system device.

Further, the abstract interfaces 122, 152 handle data (which may be synchronous or asynchronous) communicated from the driver to the client.
In the case of synchronous communication, the driver 154 sends data to the client 110 when requested.
, 114 only. Data is transferred across OS driver boundaries as described in connection with client and driver communication.

Asynchronous communication allows the driver to send client data (eg, messages)
Occurs when the client wants to send without asking for it. Note that the driver only informs the client that it has the data and the client must retrieve that data synchronously. This is summarized by the following steps.

1. The driver wants to transfer data to the client. 2. The driver informs the client asynchronously through an event. 3. The client initiates a synchronous action to retrieve or read the data.

In summary, the device driver proxy 124 translates an abstract interface request from the client 110 into a call to a particular device driver system by the OS. The OS, in turn, calls the entry point of a particular driver. The OS-specific driver 142 translates the request back into a request for the driver's abstract interface (the same interface call that the client originally made). This request is for device driver core 15
Executed in 4.

Finally, when the external client accesses the driver, two interface paths can be selected. First, abstract interface 122, 1
52 is a method used by an internal client (eg, a client developed by a set-top manufacturer) as client 112 does in FIG.
Can be used. Second, the OS driver interface is client 114
May be used directly, as in FIG.

The external client is external to the set top manufacturer. An external client is any entity that needs to use a driver from a manufacturer including, for example, a middleware developer such as Liberate Technologies (TM) (San Carlos, CA, USA), or an OS developer such as Microsoft. Also includes.

FIG. 2 illustrates a device driver abstract interface for use with an operating system that does not have a dedicated device drive interface in accordance with the present invention.

Hierarchical model 200 includes levels 210, 250 and 260. Bottom level 260 includes hardware device 262. The next abstract level 250 is the device driver abstract interface 252, device driver core control 254,
And OS includes specific driver assistance 256.

The next level 210 includes a client 212 that uses an abstract interface 252.

In particular, FIG. 2 relates to a set top system including an OS without a device driver interface. An example of such an OS is Mentor Graphics Corporatio
It is a VRTX of n (Wilsonville, Oregon, USA).

This layered architecture is compressed when the OS is dedicated and when the OS requires the use of a particular interface (eg most layers are not needed).
To be done. Here, the client 212 again looks at the device driver 254 using the device driver abstract interface 252. However, the client connects directly to the driver core 254. Only the abstract interface 252 is available under the OS without a dedicated drive interface.

Similarly, the device driver 254 looks at the client via the interface 252 to enable bidirectional communication.

The present invention provides an abstract driver for a device driver of a set top terminal.
It will be appreciated that it provides an interface.

The advantages of the present invention are as follows. The device driver will always look the same to clients that use the abstract interface. The client does not have to be redeveloped for each operating system. Also,
The client cannot say or see the difference between running two very different operating systems (see Figures 1 and 2). The key point is that the device driver assists the abstract interface so that the client can be developed once and used across the operating system.

Furthermore, the client always looks the same for driver core control. The core logic can be between clients that use abstract interfaces / proxies, clients that use interfaces of OS drivers without abstract interfaces / proxies, or clients that directly access the core, as shown in Figure 2. Can't tell the difference between.

The driver core control subsystem is executed in a way that is independent of the OS. Typically, this subsystem requires a lot of effort (manpower of all driver development) for development. However, because the driver core control subsystem of the present invention need only be developed once and can be used across different OS platforms, the abstract device driver model can significantly improve the time to market for a new set top.

Furthermore, the present invention enables the use of the user interface of other device drivers.

Although the present invention has been described in relation to particular embodiments, those skilled in the art can make various adaptations and modifications without departing from the spirit and scope of the invention as claimed. It will be appreciated that can be done.

For example, although the present invention has been discussed in the context of cable or satellite television broadband communication networks, local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), the Internet, intranets, It will also be appreciated that the Internet, or a combination thereof, can be used.

Moreover, the present invention can be implemented using known hardware, firmware and / or software techniques.

[Brief description of drawings]

FIG. 1 shows an interface model of a device driver for use with an operating system having a dedicated device driver interface according to the present invention.

FIG. 2 shows an interface model of a device driver for use with an operating system that does not have a dedicated device driver interface according to the invention.

[Procedure amendment]

[Submission date] June 24, 2002 (2002.6.24)

[Procedure Amendment 1]

[Document name to be amended] Statement

[Name of item to be amended] Claims

[Correction method] Change

[Contents of correction]

[Claims]

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW (72) Inventor Del Sword, Chris             Pennsylvania, USA 18964,             Sounderton, Heatherfield Dora             Eve 229 (72) Inventor Plettshee, David A.             18914 Pennsylvania, USA             Chalfont, Pine Oak Lane             3398 (72) Inventor Bernbaum, Jack Em             18966, Pennsylvania, United States             Southampton, Nicole Drive 559 F-term (reference) 5B014 EB03 FB03 [Continued summary] Direct access to the interface is therefore maintained It In the second example, the architecture is dedicated (OS (Includes specific) device driver interfaces I'm sorry. Therefore, the device driver core control is Interface service request from client Changes to a specific call to the device driver by the OS. In order to convert, the first abstract interface Client, so that the client Seen to interface directly with Liver Core Control Get

Claims (15)

[Claims] 1. A method for enabling communication between a client and a device driver of a terminal having a particular operating system associated with which the device driver operates, the method comprising a client having an operating system independent format. A method comprising providing a first abstract interface for converting a service request into a call to a device driver having a format compatible with a particular operating system. 2. A first abstract for converting a message from a device driver in a particular operating system format into a corresponding message in an operating system independent format for use by a client. The method of claim 1, including the step of using an interface. 3. The method of claim 1, wherein the terminal is a network subscriber television terminal. 4. The method of claim 1, wherein the terminal is on a broadband communication network. 5. The first abstract interface is adapted to provide a call to a device driver in any one of a plurality of different formats compatible with a corresponding plurality of different operating systems. The method described in. 6. The method of claim 1, further comprising the step of providing a call to a device driver via an interface of the device driver operating according to a particular operating system. 7. The device driver interface is adapted to receive a second call directly from another client having a format compatible with a particular operating system, and the device driver interface is adapted to receive the second call. 7. The method of claim 6, wherein a second call is made to the device driver via the abstract interface. 8. A first abstract interface for providing a call to a device driver through an interface of a device driver in any one of a plurality of different formats compatible with corresponding different operating systems. 7. The method of claim 6, adapted to. 9. A second abstract interface for converting a message from a device driver in a compatible format into a corresponding message in an operating system independent format for use by a client. 7. The method of claim 6 including the step of providing. 10. The method of claim 9, further comprising the step of providing a message in an operating system independent format for use by a client via the first abstract interface. 11. The second abstract interface converts a message to a client from one of a plurality of different formats compatible with a corresponding plurality of different operating systems to a format independent of the client operating system. 10. The method of claim 9, adapted to: 12. A device for enabling communication between a client and a device driver of a terminal having a particular operating system associated with which the device driver operates, from a client having an operating system independent format. A device comprising means for providing a first abstract interface for converting a service request into a call to a device driver having a format compatible with a particular operating system. 13. A method for enabling communication between a client and a device driver of a terminal having a particular operating system associated with which the device driver operates, the device driver being in the format of the particular operating system. Providing a first abstract interface for converting a message in a corresponding message in a format independent of an operating system for use by a client. 14. The first abstract interface formats a message from one of a plurality of different formats compatible with a corresponding plurality of different operating systems into an operating system independent format for use by a client. 14. The method of claim 13, adapted for conversion to. 15. A device for enabling communication between a device driver of a terminal having a specific operating system associated with which the device driver operates and a client, the device driver having a specific operating system format. Device, including means for providing a first abstract interface for converting a message in a corresponding message in a format independent of an operating system for use by a client.