EP1287436A2

EP1287436A2 - Abstract device driver model for the portability of device drivers across different operating system platforms

Info

Publication number: EP1287436A2
Application number: EP00992393A
Authority: EP
Inventors: Robert Gazda; Chris Del Sordo; David A. Prezuhy; Jack M. Birnbaum
Original assignee: Arris Technology Inc; General Instrument Corp
Current assignee: Arris Technology Inc
Priority date: 1999-12-21
Filing date: 2000-12-06
Publication date: 2003-03-05
Also published as: CN1434942A; JP2003521027A; WO2001046819A2; WO2001046819A3; KR20020073481A; CA2395468A1; AU4310001A

Abstract

An abstract interface model for device drivers in a set-top terminal, such as for use in a cable or satellite television subscriber network. In a layered software architecture, a device driver abstract interface model allows communication between a client (112, 212) and the device driver (154, 254) regardless of the operating system (OS) under which the device driver operates. In a first embodiment, the architecture includes a dedicated (OS-specific) device driver interface (132), and a proxy uses a first abstract interface (122) to convert interface service requests from a client (112) into OS-specific calls to the device driver (154). For a client that directly accesses a dedicated (OS-specific) device driver interface (132), a second abstract interface (152) is used to convert the interface service requests into OS-specific calls to the device driver (154). Direct access to the OS-specific device driver interface (132) is therefore maintained.

Description

ABSTRACT DEVICE DRIVER MODEL FOR THE PORTABILITY OF DEVICE DRIVERS ACROSS DIFFERENT OPERATING SYSTEM

PLATFORMS

BACKGROUND OF THE INVENTION

The present invention relates to the field of digital set-top software/firmware for use, e.g., in a cable or satellite television subscriber network. In particular, an abstract interface model is provided for device drivers in a set-top terminal. The recent advent of digital set-top terminals has spurred the growth of subscriber television networks, such as cable/satellite television networks. Such terminals can support increased levels of programming services and a variety of software-based applications and functions, such as an electronic program guide, stock or weather banners, shop and bank at home services, games, and the like. Moreover, this trend is expected to continue with the convergence of telephone, television and computer networks, and the rise of in- home computer networks.

Each terminal includes different hardware devices, for example, tuners, demodulators, MPEG-2 Decoders (e.g., audio, video, and data), video encoders, audio mixers, and so forth, which are controlled by respective drivers.

Moreover, each terminal uses an operating system (OS) platform for controlling the functions of the terminal . The OS has a hierarchical structure wherein functions are separated according to their level of abstraction. At the bottom of the structure, the least abstract level or layer is the hardware device level . The next higher level is the device driver level . At the top of the structure, the most abstract level is typically the client level. Additionally, each level manages a set of objects, which can be hardware or software objects, and defines operations that can be carried out on the objects. However, conventionally it is necessary for a device driver to be implemented separately for each operating system platform, e.g., for different set-top manufacturers, or different set-top models from the same manufacturer. Moreover, a single hardware platform may be required to support different OS platforms. It is even possible for different terminals in the same network to have different operating systems .

Generally, continual operating system changes in set-top terminals is a result of improvements, cost reductions, new components, and second source manufacturers. This is problematic since, even though each network generally uses a single OS platform, the terminal manufacturer must create different device drivers for the different operating systems in different networks. The device driver for the OS of one network cannot be easily migrated to another OS in another network.

The need to develop and provide updated device driver software/firmware to the terminals leads to additional expense for the terminal manufacturer and network provider.

Specifically, device drivers for a particular OS are tightly bundled to the OS, which means each driver contains OS-specific details throughout the driver's implementation, so a full development cycle is required to develop drivers for each OS platform.

These problem are compounded by the continual upgrading and replacement of terminals in networks as technology advances . Accordingly, it would be desirable to provide a device driver abstract interface model that allows the development of a single set of device driver code, and device user code that will compile and execute under different set-top operating systems. The interface should allow a device driver to be implemented only once while being usable under several operating systems and set-top platforms. One such suitable platform is the DCT5000 series terminals, manufactured by General Instrument Corporation, the assignee hereof. The interface should allow two-way communication between the device driver and a client.

The interface should ensure that the hardware device appears the same to the terminal's client (e.g., whatever application or other entity is communicating with the device) regardless of the OS under which the hardware device operates. Similarly, the client should appear the same to the actual device driver regardless of the operating system.

The interface should allow the sharing of architecture and code across both OS platforms and hardware platforms . The interface should be usable with operating systems that have, or do not have, a dedicated (operating system-specific) device driver interface.

The interface should be implementable using object-oriented or procedure-oriented programming languages .

The present invention provides a device driver abstract interface model having the above and other advantages .

SUMMARY OF THE INVENTION

The present invention relates to an abstract interface model for device drivers in a set-top terminal . The invention allows the development of driver core logic only once. The core still needs to be compiled separately for each OS platform.

In a particular embodiment, a method is provided for allowing communication between a client and a device driver in a terminal, where the terminal has an associated specific operating system under which the device driver operates . The method includes the step of providing a first abstract interface for converting a service request from the client that has a format that is operating system-independent into a call to the device driver that has a format that is compatible with the specific operating system.

In particular, the first abstract interface is adapted to provide the call to the device driver in any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems .

When a dedicated (OS-specific) device driver interface is present, the device driver interface is adapted to receive a second call directly from another client that has a format that is compatible with the specific operating system. The second call does not pass through the first abstract interface. Moreover, the device driver interface provides the second call to the device driver via a second abstract interface. A related method for allowing communication between a client and a device driver in a terminal, where the terminal has an associated specific operating system under which the device driver operates, includes the step of providing a first abstract interface for converting a message from the device driver that is in the format of the specific operating system to a corresponding message in an operating system- independent format for use by the client. The first abstract interface is adapted to convert the message from any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems into the operating system- independent format for use by the client.

Corresponding apparatuses are also presented.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a device driver abstract interface model for use with an operating system that has a dedicated device driver interface in accordance with the present invention.

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

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to an abstract interface model for device drivers in a set-top terminal . Known object-oriented design techniques provide a method for abstractly creating objects. Mainly, the designer can create an object that provides an abstract interface without directly knowing the details of the instantiation of the object. This occurs dynamically, at the run time of the software.

The invention extends or modifies this idea as follows. Only a single driver interface is created for all operating systems. This is done at the time the source code is compiled, and only happens once (statically) .

Accordingly, when a new OS platform is developed, at most, a proxy, an OS-specific driver, and the OS- specific driver support require development. This typically represents only about 10% or less of the driver development cycle, thereby resulting in significant cost and time savings .

Specifically, all of the device driver logic is located or implemented in the device driver core control. This module or sub-system resides immediately above the hardware device level, and communicates with the hardware device either directly, or with the assistance of the OS-specific driver support subsystem. Note that the core control includes the majority of all the code in this architecture. The device driver core control implements the logic defined in the device driver abstract interface. This interface defines what services the driver must provide. The core control includes all code required to provide those services .

FIG. 1 illustrates a device driver abstract interface model for use with an OS that has a dedicated device driver interface in accordance with the present invention. The dedicated device driver interface 130 may be, e.g., Windows CE from Microsoft (tm) .

A layered device driver model 100 includes a number of levels 110, 120, 130, 140, 150 and 160. Typically, the OS requires just a driver implemented to its interface, in one level. A bottom level 160, which is the least abstract level, includes the hardware device itself 162 in the set-top terminal.

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

The next abstract level 120 includes the first device driver abstract interface 122, and a device driver proxy 124.

The next abstract level 110, which is the highest level, includes a client 112 that is using the device driver abstract interface 122, and a client 114 that is using the OS device driver interface 132. Note that while only one device is shown, the invention is suitable for use with any number of devices in a set-top.

In the architecture of FIG. 1, the OS-specific device driver 142 controls or drives the device driver core control 154 using the second device driver abstract interface 152. In particular, this level 140 with the OS-specific device driver 142 converts or transforms OS-specific device driver calls (tied specifically to an OS) into abstract device driver calls that are defined by the device driver abstract interface 152.

The OS itself invokes services within the OS- specific device driver 142 through the operating system's defined driver interface 132. The OS may be

Microsoft (tm) Windows CE, for example. This OS invokes calls having the format "xxx_IOCTL" within a Windows CE Device Driver, where "xxx" represents the Windows CE names of the device. Regarding driver calls, Windows CE represents an example where a proxy would invoke a "DeviceloControl" call to passing the Win CE name of the device.

The device driver proxy 124 represents the device driver 154 to the client 112 using the abstract interface 122, which is functionally the same as the device driver abstract interface 152 that is implemented by the device driver core control 154. These clients can include, e.g., middleware and applications. Hence, it appears as if the client is interfacing directly to the driver core itself. Moreover, the proxy 124 converts or transforms interface service requests from the client 112 into their associated OS-specific system device.

Additionally, the abstract interfaces 122, 152 handle data that is communicated from the driver to the client, which can be synchronous or asynchronous. With synchronous communication, the driver 154 only provides data to the client 110, 114 when asked. The data is transferred across the OS driver boundary as described in connection with the client to driver communication. Asynchronous communication occurs when a driver wishes to send a client data (e.g., a message) without the client asking for it. Note that the driver can only inform the client that it has data, and the client must then synchronously retrieve the data. This is summarized by the following steps:

1. Driver wishes to transfer data to the client.

2. The driver signals the client asynchronously through an event .

3. Client issues a synchronous operation to retrieve or read the data.

To summarize, the device driver proxy 124 converts abstract interface requests from a client 110 into OS- specific device driver system calls. The OS, in turn, invokes OS-specific driver entry points. The OS- specific driver 142 converts the request back into a driver abstract interface request, which is the same interface call that the client originally performed. This request is executed in the device driver core 154. Finally, external clients can chose two interface paths when accessing drivers. First, the abstract interface 122, 152 can be used in the manner the internal clients (e.g., clients developed by the set- top manufacturer) use it, such as the client 112 is doing in FIG. 1. Second, the OS driver interface can be directly used, as the client 114 is doing in FIG 1. An external client is external to the set-top manufacturer. External clients include any entity that needs to use the manufacturer's driver including, e.g., a middleware developer such as Liberate Technologies (tm) , San Carlos, California, USA, or an OS developer such as Microsoft.

FIG. 2 illustrates a device driver abstract interface model for use with an operating system that does not have a dedicated device driver interface in accordance with the present invention. The hierarchical model 200 includes levels 210,

250 and 260. The bottom level 260 includes the hardware device 262. The next abstract level 250 includes a device driver abstract interface 252, a device driver core control 254, and an OS-specific driver support 256.

The next level 210 includes the client 212 that is using the abstract interface 252.

In particular, FIG. 2 refers to a set-top system containing an OS without a device driver interface. An example of such an OS is VRTX from Mentor Graphics Corporation, Wilsonville, Oregon, USA.

This layered architecture compresses (e.g., fewer layers are required) when the OS does not require the use of a dedicated OS-specific interface. Here, the client 212, again, views the device driver 254 using the device driver abstract interface 252. But, the client directly connects to the driver core 254. Only the abstract interface 252 is available under the OS without dedicated driver interfaces.

Similarly, the device driver 254 views the client via the interface 252 to allow two-way communication. Accordingly, it can be seen that the present invention provides an abstract interface model for device drivers in a set -top terminal.

The benefits of the invention are as follows. To clients using the abstract interface, the device driver always appears the same. The client does not need to be redeveloped for each operating system. Also, the client cannot tell or see the difference between the two very different OS implementations (see FIGs 1 and 2) . The driver appears the same. A key point is that the device drivers support an abstract interface allowing clients to be developed once, and utilized across operating systems.

Additionally, to the driver core control, the client always appears the same. The core logic cannot tell the difference between clients using the abstract interface/proxies, clients using the OS driver interface without the abstract interface/proxies, or clients directly accessing the core, as in FIG. 2. The driver core control sub-system is implemented in a OS-independent manner. Typically, this sub-system requires a great amount of effort to develop (e.g., up to 90% of all driver development man-hours) . However, since the driver core control sub-system of the invention only needs to be developed once, and can then be utilized across different OS platforms, the abstract device driver model can greatly improve the time to market for new set-top products.

Moreover, the invention allows the use of alternative device driver user interfaces. Although the invention has been described in connection with various specific embodiments, those skilled in the art will appreciate that numerous adaptations and modifications may be made thereto without departing from the spirit and scope of the invention as set forth in the claims .

For example, while the invention was discussed in connection with a cable or satellite television broadband communication networks, it will be appreciated that other networks such as local area networks (LANs) , metropolitan area networks (MANs) , wide area networks (WANs), internets, intranets, and the Internet, or combinations thereof, may be used.

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

Claims

What is claimed is:

1. A method for allowing communication between a client and a device driver in a terminal, said terminal having an associated specific operating system under which the device driver operates, comprising the step of: providing a first abstract interface for converting a service request from the client that has a format that is operating system-independent into a call to the device driver that has a format that is compatible with the specific operating system.

2. The method of claim 1, comprising the further step of: using the first abstract interface for converting a message from the device driver that is in the format of the specific operating system to a corresponding message in the operating system- independent format for use by the client.

3. The method of claim 1, wherein: the terminal is a subscriber television terminal in a network.

4. The method of claim 1, wherein: the terminal is in a broadband communication network.

5. The method of claim 1, wherein: the first abstract interface is adapted to provide the call to the device driver in any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems.

6. The method of claim 1, comprising the further step of : providing the call to the device driver via a device driver interface that operates according to the specific operating system.

7. The method of claim 6, wherein: the device driver interface is adapted to receive a second call directly from another client that has a format that is compatible with the specific operating system; and the device driver interface provides the second call to the device driver via a second abstract interface .

8. The method of claim 6, wherein: the first abstract interface is adapted to provide the call to the device driver via the device driver interface in any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems.

9. The method of claim 6, comprising the further step of: providing a second abstract interface for converting a message from the device driver that is in the compatible format to a corresponding message in the operating system-independent format for use by the client .

10. The method of claim 9, comprising the further step of: providing the message in the operating system- independent format for use by the client via the first abstract interface.

11. The method of claim 9, wherein: the second abstract interface is adapted to convert the message to the client from any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems to the client's operating system-independent format .

12. An apparatus for allowing communication between a client and a device driver in a terminal, said terminal having an associated specific operating system under which the device driver operates, comprising: means for providing a first abstract interface for converting a service request from the client that has a format that is operating system-independent into a call to the device driver that has a format that is compatible with the specific operating system.

13. A method for allowing communication between a client and a device driver in a terminal, said terminal having an associated specific operating system under which the device driver operates, comprising the step of: providing a first abstract interface for converting a message from the device driver that is in the format of the specific operating system to a corresponding message in an operating system- independent format for use by the client.

14. The method of claim 13, wherein: the first abstract interface is adapted to convert the message from any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems into the operating system-independent format for use by the client.

15. An apparatus for allowing communication between a client and a device driver in a terminal, said terminal having an associated specific operating system under which the device driver operates, comprising: means for providing a first abstract interface for converting a message from the device driver that is in the format of the specific operating system to a corresponding message in an operating system- independent format for use by the client.