System, method, and computer program product for controlling a driver utilizing scripts

A system, method, and computer program product are provided for controlling a driver. In use, at least one script is received. Further, control code is generated based on the script. The control code is then executed during runtime for controlling a driver.

FIELD OF THE INVENTION

The present invention relates to drivers, and more particularly to controlling a driver.

BACKGROUND

To date, many hardware suppliers must manually customize their drivers for each customer [e.g. original equipment manufacturer (OEM), end user, etc.] who desires driver customization. To accomplish this, each customer typically selects from a plurality of predetermined fixed functions, and the hardware supplier must manually encode the desired functionality in the supporting driver (e.g. by providing registry keys for enabling the aforementioned fixed functions, etc.). Unfortunately, this process is tedious and must be repeated for each customer who desires customization.

For example, such customization often results in a configuration file or the like being generated for use by each customer in conjunction with the hardware driver. Further, intimate knowledge of the hardware and driver is typically required for mapping the desired functionality requested by each customer to the underlying capabilities of the hardware. These issues are further exacerbated in situations where a customer base and number of fixed functions grow in size.

SUMMARY

A system, method, and computer program product are provided for controlling a driver. In use, at least one script is received. Further, control code is generated based on the script. The control code is then executed during runtime for controlling a driver.

DETAILED DESCRIPTION

FIG. 1shows a method100for controlling a driver, in accordance with one embodiment. In the context of the present description, such driver may refer to any software that interfaces hardware for controlling at least one aspect thereof. Of course, such hardware may include a processor, network adapter, and/or any other integrated circuit or system including at least one integrated circuit, for that matter.

As shown, at least one script is received. Note operation102. In the context of the present description, such script may refer to any program or sequence of instructions that is interpreted to generate other code (to be set forth hereinafter in greater detail).

Non-limiting examples of script languages that may be used to generate such script may include, but are not limited to Perl, Rexx, JavaScript, Tcl/Tk, VBScript, C++, etc. Of course, other proprietary scripts may be used as well, as will be set forth hereinafter in greater detail. In one optional embodiment, the script may include a language that is easier for a human to program with, but requires conversion to other code that, in turn, is ultimately executed.

As will be elaborated upon during the description of later embodiments, the script may be received in any desired manner. For example, in one embodiment, the script may be received from a customer [e.g. an original equipment manufacturer (OEM), etc.] of the aforementioned hardware. In another embodiment, the script may be received from an end user of the hardware. Of course, the script may be received in any desired manner from any desired source (e.g. even the hardware supplier, in one embodiment).

Next, in operation104, control code is generated based on the script. In the context of the present description, such control code may include any code that takes on a different format than the script received in operation102. Just as one possible example, the control code may take the form of byte code. In one embodiment, the control code may be generated by compiling the script.

The control code is then executed during runtime for controlling a driver. See operation106. Such runtime may refer to any time during which the driver is running. Further, the control code may be executed for controlling any aspect of the driver which may, in turn, control the aforementioned hardware. It should be noted that such control may be administered utilizing any desired mechanism (e.g. virtual machine, a plug-in, control module, etc.).

By this design, the foregoing features may, in one embodiment, allow customers, end users, etc. to define desired functionality utilizing the script. Such script may then be compiled to generate control code (e.g. byte code, etc.). During runtime, this control code may be executed in conjunction with the driver for customizing driver functionality to perform the customer/user-specific functionality, under the direction of the control code. In one embodiment, such feature may allow a hardware supplier to, at least in part, avoid having to perform such customization on a manual basis.

FIG. 2shows a system200for controlling a driver, in accordance with one embodiment. As an option, the present system200may be implemented to can out the method100ofFIG. 1. Of course, however, the system200may be implemented in any desired environment. It should also be noted that the aforementioned definitions may apply during the present description.

As shown, at least one script may be generated in one of two ways. For example, an OEM202may simply use a script language to generate at least one script. Such script may then be delivered in any desired manner. For example, such script may be communicated over a network such as the World Wide Web204. Of course, other modes of delivery (e.g. using a disc, jump drive, print out, etc.) are also contemplated. In one embodiment, the OEM202may be provided with a graphical user interface for facilitating the generation of the script, as will be set forth below in greater detail.

Still yet, an end user206may have access to a graphical user interface208with which the user may enter the script. As an option, the graphical user interface208may be accessible over a network (e.g. be web-based, etc.). Such graphical user interface208may, in one embodiment, simply serve as an interface for allowing entry of the script, and/or include enhanced features such as a tutorial, library of scripts, and/or any other mechanism for facilitating entry of the necessary input to generate the script.

In any case, the script is delivered to a compiler210, which serves to compile the received script to generate control code (e.g. byte code, etc.), during compile time as shown. In one embodiment, the control code may be stored in a file. Such control code may, in turn, be incorporated and/or interfaced with a driver214(e.g. kernel mode driver, etc.) that, in turn, controls a processor216. As an option, the control code may be fed to a virtual machine212that exists in conjunction with the driver214, for the specific purpose of being executed by the virtual machine212for controlling the driver214.

In the context of the present description, the virtual machine212may include any program that provides an operating environment that works in conjunction with, yet independent of the driver214. Non-exhaustive examples of the virtual machine212include an HTML virtual machine, a JAVA™ virtual machine, etc. More information regarding one way the virtual machine212may be used to control the driver214will be set forth in greater detail during the description ofFIG. 3.

While the compiler210is shown to be separate from the virtual machine212and the driver214inFIG. 2, it should be noted that such components may or may not be integrated, as desired. To this end, embodiments are completed where the script is compiled using the virtual machine212and/or the driver214, etc.

FIG. 3shows a method300for performing controlling a driver using control. Code executed utilizing a virtual machine, in accordance with another embodiment. As an option, the present method300may be implemented in the context of the functionality and architecture ofFIGS. 1-2. For example, the method300may represent the functionality of the virtual machine212and/or the driver214ofFIG. 2. Of course, however, the method300may be carried out in any desired environment. It should also be noted that the aforementioned definitions may apply during the present description.

As shown inFIG. 3, a driver (e.g. the driver214ofFIG. 2) may be installed. Note operation302. Such installation may be performed by an OEM, end user, and/or any other entity for the purpose of interfacing any desired hardware. In one embodiment, the driver may have installed therewith a virtual machine (e.g. the virtual machine212ofFIG. 2). Before or after such installation of operation302, the virtual machine may be equipped with control code adapted to control the virtual machine to, in turn, control the driver for providing additional (e.g. customized) functionality.

After installation, the virtual machine may be executed during runtime. See operation304. In one embodiment, this may involve execution of the virtual machine in conjunction with the driver. For example, in one embodiment, the virtual machine may be a plug-in installed in conjunction with the driver such that, upon execution of the driver, the virtual machine is also executed. In another embodiment, the virtual machine may be a separate module that executes in response to operation of the driver or visa-versa, etc.

During use, it is determined when any functionality provided by the virtual machine is invoked. See decision306. In one embodiment, such functionality may be trigged by input, actions taken by, output of the driver for any other application program/hardware) or any other triggering event, for that matter. Based on the trigger and any particular parameters, the virtual machine may provide any desired specific resultant functionality that would not otherwise be performed by the driver, etc. See operation308. It should be noted that such functionality may modify any already-existing functionality and/or simply supplement already-existing functionality with new functionality.

In one embodiment, the virtual machine may trigger any desired predetermined fix functions that are within the capabilities of the hardware and/or impact any desired flow control, etc. Just as one possible example, the virtual machine may monitor for a situation where a particular hot key is pressed by the user, a specific state (e.g. standby, performance mode, boot-up sequence, etc.) is invoked, etc., so that a corresponding reaction may be carried out. For example, based on any of the foregoing triggers (or any other), the hardware (under the control of the driver) may be controlled to perform a power savings operation, performance-enhancing task, feature-enabling action, a specific flow, etc.

Strictly as an option, additional functionality may be added at a time after the installation of the driver. For instance, such additional functions may be updated utilizing additional scripts. Such scripts may be received in any desired manner. For example, an existing script may be modified, a supplement script may be received, etc. To this end, the modified or supplemental script may be compiled and added to or used to replace the control code that serves to manage the virtual machine/driver.

FIG. 4shows a script400for indicating functionality to be implemented in conjunction with a driver, in accordance with another embodiment. As an option, the present script400may be used in the context of the functionality and architecture ofFIGS. 1-3. For example, the script400may be input to the compiler210ofFIG. 2for generating control code, etc. Of course, however, the script400may be used in any desired environment. Again, the aforementioned definitions may apply during the present description.

As shown, the script400may include a plurality of commands4.02, parameters404, etc. In use, such commands402and parameters404may be selected and used to define various desired functionality to be provided in association with driver execution. As shown, the script400may include commands402that identify a particular hot key, a specific state (e.g. standby, performance mode, boot-up sequence, etc.), etc. Still yet, the parameters404may include various actions, for example, to be taken in association with the aspects associated with the commands402. Of course, the forgoing exemplary commands402and parameters404ofFIG. 4are set forth for illustrative purposes only and should not be construed as limiting in any manner whatsoever.

FIG. 5shows control code500for controlling a driver to perform desired functions, in accordance with another embodiment. As an option, the present control code500may be used in the context of the functionality and architecture ofFIGS. 1-3. For example, the control code500may be output from the compiler210ofFIG. 2for use in association with the virtual machine212to control the driver214, etc. Of course, however, the control code500may used in any desired environment. Again, the aforementioned definitions may apply during the present description.

As shown, the control code500may include a plurality of op code commands502, parameters504, etc. Unlike the commands402, parameters404, etc. of the script400ofFIG. 4, however, such op code commands502and parameters504are compiled in a form that may be executed in association with a virtual machine and driver, for controlling the driver. As shown, the commands502and parameters504may include a jump and other instructions, as well as specific functions and various logical operations (e.g. Boolean, if-then, etc.).

Again, the forgoing exemplary commands502, parameters504, etc. ofFIG. 5are set forth for illustrative purposes only and should not be construed as limiting in any manner whatsoever. For example, in some embodiments, the specific commands502and parameters504may vary as a function of what hardware is being interfaced by the driver. In one embodiment, for instance, the available commands502and parameters504may reflect all of the capabilities of the particular hardware.

FIG. 6illustrates an exemplary system600in which the various architecture and/or functionality of the various previous embodiments may be implemented. For example, the driver214and virtual machine212ofFIG. 2may be used to interface and control any of the hardware of the system600ofFIG. 6. Of course, the system600should not be construed as limiting in any manner whatsoever in this regard.

As shown, a system600is provided including at least one host processor601which is connected to a communication bus602. The system600also includes a main memory604. Control logic (software) and data are stored in the main memory604which may take the form of random access memory (RAM).

The system600also includes a graphics processor606and a display608, i.e. a computer monitor. In one embodiment the graphics processor606may include a plurality of shader modules, a rasterization module, etc. Each of the foregoing modules may even be situated on a single semiconductor platform to form a graphics processing unit (GPU).

The system600may also include a secondary storage610. The secondary storage610includes, for example, a hard disk drive and/or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, etc. The removable storage drive reads from and/or writes to a removable storage unit in a well known manner.

Computer programs, or computer control logic algorithms, may be stored in the main memory604and/or the secondary storage610. Such computer programs, when executed, enable the system600to perform various functions. Memory604, storage610and/or any other storage are possible examples of computer-readable media. Stored on any of the aforementioned computer-readable media may be a driver/virtual machine for interfacing arty of the hardware disclosed herein.

In one embodiment, the architecture and/or functionality of the various previous figures may be implemented in the context of the host processor601, graphics processor606, an integrated circuit (not shown) that is capable of at least a portion of the capabilities of both the host processor601and the graphics processor606, a chipset (i.e. a group of integrated circuits designed to work and sold as a unit for performing related functions, etc.), and/or any other integrated circuit for that matter.

Further, while not shown, the system600may be coupled to a network [e.g. a telecommunications network, local area network (LAN), wireless network, wide area network (WAN) such as the Internet, peer-to-peer network, cable network, etc.) for communication purposes.