Method and apparatus for intercommunications amongst device drivers

• US 8,621,488 B2
• Filed: 06/30/2011
• Issued: 12/31/2013
• Est. Priority Date: 01/07/2007
• Status: Active Grant

• Current Assignee: Apple Inc.
• Original Assignee: Apple Inc.
• Inventors: de Cesare, Joshua, Douglas, Simon, Kosut, Alexei Elias
• Primary Examiner(s): Ho, Andy
• Assistant Examiner(s): Kraft, Shih-Wei
• Application Number:
  US13/174,486
• Publication Number:
  US 20110258640A1
• Time in Patent Office: 915 Days
• Field of Search: None
• US Class Current: 719/321
• CPC Class Codes: G06F 9/4411 Configuring for operating with peripheral devices; Loading of device drivers

Abstract

Techniques for intercommunication amongst device drivers are described herein. In one embodiment, an application programming interface (API) is provided by a kernel of an operating system (OS) running within a data processing system. The API is accessible by device drivers associated with multiple devices installed in the system. In response to a request from a first instance of a driver the API, information indicating whether another instance of the same driver is currently started is returned via the API. Other methods and apparatuses are also described.

Claims

1. A computer system architecture, comprising:

a plurality of device drivers loaded in a kernel of an operating system of a computer, each of the device drivers corresponding to a device presented in the computer;

an application programming interface (API) for coupling the kernel with the plurality of device drivers, wherein in response to a request received from a first instance of a device driver via the API for determining whether a second instance of the device driver is currently loaded, the kernel is to

perform a lookup in a data structure to determine whether the data structure stores a second driver handle of a second instance of the device driver, wherein the second driver handle stored in the data structure indicates that the second instance of the device driver has been loaded,

return via the API a first driver handle of the first instance of the device driver if the second instance of the device driver has not been loaded, and

return via the API the second driver handle of the second instance of the device driver if the second instance of the device driver has been loaded, wherein the first driver handle is compared with the second driver handle to determine whether the second instance of the device driver has been loaded; and

a device map maintained by the kernel, the device map having a plurality of entries and each corresponding to a device, wherein the device map includes a first field to store an identifier of a corresponding device and a second field to store a driver handle of a device driver associated with the corresponding device, wherein the device map is accessible by the kernel as part of the API to determine whether an instance of a device driver for a particular device is loaded, wherein the API returns a driver handle of an existing driver specified in a second field of a device, indicating that the existing driver has been loaded, wherein the driver handle returned by the API is examined to determine whether the first driver handle and the driver handle returned by the API are identical, and wherein the kernel is to start the first instance of the driver if the first driver handle and the driver handle returned by the API are identical, and unload the first instance of the driver if the first driver handle and the driver handle returned by the API are different.

2. The architecture of claim 1, wherein the API is invoked during an initialization of the first instance of the device driver.

3. The architecture of claim 1, wherein a lock is acquired prior to accessing the data structure to prevent others from accessing the data structure, and wherein the lock is released after accessing the data structure to allow others accessing the data structure.

4. The architecture of claim 1, wherein if the second instance of the device driver has not been loaded, the first driver handle of the first instance is inserted into the second field of an entry of the device map that is associated with the device driver.

5. The architecture of claim 1, wherein if the second instance of the device driver has been loaded, the second driver handle returned from the API is used by the first instance of the device driver to communicate with the second instance of the device driver.

6. The architecture of claim 1, wherein a driver handle of a device driver comprises a pointer pointing to a memory location at which the device driver is currently loaded.

7. The architecture of claim 1, wherein an identifier of a device is represented by a universally unique identifier (UUID) or a globally unique identifier (GUID).

8. A computer implemented method, comprising:

a first instance of a driver calling an application programming interface (API) maintained by a kernel of an operating system, the first instance of the driver being identified via a first driver identifier and loaded by the operating system executed within a data processing system, wherein the kernel is to perform a lookup in a data structure to determine whether the data structure stores another driver handle of a second instance of the driver, wherein the driver handle stored in the data structure indicates that the second instance of the driver has been initialized;

in response to a result of calling the API, the first instance of the driver determining whether the second instance of the driver has been initialized by comparing a driver identifier returned from the API against its own driver identifier, wherein the kernel is to return via the API a second driver identifier, the second driver identifier identifying one of the first instance and second instance of the driver;

maintaining a device map by the kernel, the device map having a plurality of entries and each corresponding to a device, wherein the device map is accessible by the kernel as part of the API to determine whether an instance of a driver for a particular device is loaded, wherein the device map includes a first field to store an identifier of a corresponding device and a second field to store a driver identifier of a device driver associated with the corresponding device, wherein the API returns a driver identifier of an existing driver specified in a second field of a device, indicating that the existing driver has been loaded;

examining the second driver identifier returned by the API to determine whether the first and second driver identifiers are identical;

starting the first instance of the driver if the first and second driver identifiers are identical; and

unloading the first instance of the driver if the first and second driver identifiers are different.

9. The method of claim 8, further comprising:

acquiring a lock prior to accessing the data structure to prevent others from accessing the data structure; and

releasing the lock after accessing the data structure to allow others accessing the data structure.

10. The method of claim 8, further comprising, if the second instance of the device driver has not been loaded, inserting the first driver handle of the first instance into the second field of an entry of the device map that is associated with the device driver.

11. The method of claim 8, wherein the API is called during an initialization of the first instance of the driver.

12. The method of claim 8, wherein if the second instance of the device driver has been loaded, the second driver handle returned from the API is used by the first instance of the device driver to communicate with the second instance of the device driver.

13. The method of claim 8, wherein a driver handle of a device driver comprises a pointer pointing to a memory location at which the device driver is currently loaded.

14. The method of claim 8, wherein an identifier of a device is represented by a universally unique identifier (UUID) or a globally unique identifier (GUID).

15. A non-transitory machine-readable medium having instructions stored therein, which when executed by a machine, cause a machine to perform a method, the method comprising:

a first instance of a driver calling an application programming interface (API) maintained by a kernel of an operating system, the first instance of the driver being identified via a first driver identifier, wherein the kernel is to perform a lookup in a data structure to determine whether the data structure stores another driver handle of a second instance of the driver, wherein the driver handle stored in the data structure indicates that the second instance of the driver has been initialized;

in response to a result of calling the API, the first instance of the driver determining whether the second instance of the driver has been initialized by comparing a driver identifier returned from the API against its own driver identifier, wherein the kernel is to return via the API a second driver identifier, the second driver identifier identifying one of the first instance and second instance of the driver;

maintaining a device map by the kernel, the device map having a plurality of entries and each corresponding to a device, wherein the device map is accessible by the kernel as part of the API to determine whether an instance of a driver for a particular device is loaded, wherein the device map includes a first field to store an identifier of a corresponding device and a second field to store a driver identifier of a device driver associated with the corresponding device, wherein the API returns a driver identifier of an existing driver specified in a second field of a device, indicating that the existing driver has been loaded;

examining the second driver identifier returned by the API to determine whether the first and second driver identifiers are identical;

starting the first instance of the driver if the first and second driver identifiers are identical; and

unloading the first instance of the driver if the first and second driver identifiers are different.

16. The non-transitory machine-readable medium of claim 15, wherein the method further comprises:

acquiring a lock prior to accessing the data structure to prevent others from accessing the data structure; and

releasing the lock after accessing the data structure to allow others accessing the data structure.

17. The non-transitory machine-readable medium of claim 15, wherein the method further comprises, if the second instance of the device driver has not been loaded, inserting the first driver handle of the first instance into the second field of an entry of the device map that is associated with the device driver.

18. The non-transitory machine-readable medium of claim 15, wherein the API is called during an initialization of the first instance of the driver.

19. The non-transitory machine-readable medium of claim 15, wherein if the second instance of the device driver has been loaded, the second driver handle returned from the API is used by the first instance of the device driver to communicate with the second instance of the device driver.

20. The non-transitory machine-readable medium of claim 15, wherein a driver handle of a device driver comprises a pointer pointing to a memory location at which the device driver is currently loaded.

21. The non-transitory machine-readable medium of claim 15, wherein an identifier of a device is represented by a universally unique identifier (UUID) or a globally unique identifier (GUID).