Abstract:
Provided are a method, system, and program for managing a configuration file including device parameters that define attributes of at least one device. A device driver uses the device parameters to control the at least one device. A determination is made of device parameters provided with the device driver for a device, wherein the device parameters are maintained external to the configuration file. User selection of at least one of the determined device parameters is received and a parameter code for each selected device parameter is written to the configuration file.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Field of the Invention  
           [0002]    The present invention relates to a method, system, and program for including device parameters from a device driver in a configuration file.  
           [0003]    2. Description of the Related Art  
           [0004]    A tape drive or other device attached to a computer system requires the support of a device driver installed on the computer system. A device driver program functions as an interface between the computer operating system and application programs executing thereon and the device. The computer programs and operating system access the device through the device driver by communicating generic device commands that the device driver translates to device-type specific commands to control device operations.  
           [0005]    A device driver program includes a built-in configuration table having device parameters that are used when configuring and communicating with the device. Unix** systems further provide a configuration file, known as the “.conf” file, in which the user may set certain device parameters that are then used by the device driver in place of any parameters included in the configuration table compiled or provided with the device driver. During operations, the device driver will first check the configuration file (.conf), and if there are active user set parameters, then the device driver will use those active parameters included in the configuration file. Otherwise, the device driver will use the parameters in the configuration table provided (compiled) with the device driver program. For instance, a device driver is provided for tape drives. Although the device driver program can utilize the standard tape driver settings, performance is optimized by modifying the tape configuration file, known as “st.conf”, with the geometry parameters the vendor recommends for the installed tape drive. For instance, the user may define in the tape configuration file (st.conf) a maximum of four densities for a particular drive designation, e.g., Digital Linear Tape (DLT)  8000  compliant devices support a density of 0x88 for the 40 gigabyte (GB) uncompressed mode and 0x89 for 80 GB compressed mode. Additional values can be selected based on the types of cartridges and densities available for the DLT capabilities of the tape drive. Thus, users can optimize performance by properly adding settings to the configuration file to support the specific capabilities of the attached device.  
           [0006]    The settings in the configuration file comprise hexadecimal codes that have specific syntax requirements. The configuration file (.conf) file syntax is highly sensitive to typographical errors. If the user manually enters parameter settings into the configuration file that include a syntax error, then the system will display a series of error messages during the subsequent reboot. Customer support for system vendors often receive numerous calls from customers reporting system errors resulting from typographical errors in their entries in the configuration file. The customers reporting such problems are often unaware that inappropriate syntax in the codes they added to the configuration file is the source of the problem.  
           [0007]    Additionally, when users create configuration files, a subsequent update to the device driver provided by the device vendor can overwrite the configuration file, thereby eliminating the parameters the user has entered into the configuration file to optimize operations.  
           [0008]    For these reasons, there is a need in the art to provide improved techniques to allow a user to manage and modify the device configuration files.  
         SUMMARY OF THE PREFERRED EMBODIMENTS  
         [0009]    Provided are a method, system, and program for managing a configuration file including device parameters that define attributes of at least one device. A device driver uses the device parameters to control the at least one device. A determination is made of device parameters provided with the device driver for a device, wherein the device parameters are maintained external to the configuration file. User selection of at least one of the determined device parameters is received and a parameter code for each selected device parameter is written to the configuration file.  
           [0010]    In certain implementations, the determined device parameters are compiled into the device driver.  
           [0011]    In further implementations, the determined device parameters are maintained in a device parameter file external to the device driver. In such implementations, an update to the device parameter file including update device parameters for the device driver may be received. The device parameter file providing device parameters to the device driver is replaced with the update.  
           [0012]    In further implementations, user selection of one of a plurality of devices supported by the device driver is received, wherein the determined device parameters are for the selected device.  
           [0013]    Still further, a request for devices supported by the device driver is received and a call is submitted to the device driver for the supported devices. A list of supported devices is received from the device driver, wherein the user selects one of the devices on the list received from the device driver.  
           [0014]    In yet further implementations, a call is submitted to the device driver for device parameters for the device. A list of the device parameters provided with the device driver for the device is received from the device driver, wherein the determined device parameters comprise the list received from the device driver. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0015]    Referring now to the drawings in which like reference numbers represent corresponding parts throughout:  
         [0016]    [0016]FIG. 1 illustrates a computing environment in which aspects of the invention are implemented;  
         [0017]    [0017]FIGS. 2, 3,  4 , and  11  illustrate Graphical User Interface (GUI) panels to enable the user to manage and modify a configuration file used by a device driver in accordance with certain implementations of the invention;  
         [0018]    [0018]FIGS. 5 a ,  5   b ,  5   c  and  6  illustrate logic to manage and modify the configuration file in accordance with implementations of the invention;  
         [0019]    [0019]FIGS. 7 and 8 illustrate GUI panels to enter information on attached devices in accordance with certain implementations of the invention;  
         [0020]    [0020]FIG. 9 illustrates additional implementation details of the computing environment of FIG. 1 in accordance with implementations of the invention;  
         [0021]    [0021]FIG. 10 illustrates an additional computing environment in accordance with implementations of the invention; and  
         [0022]    [0022]FIGS. 12 a  and  12   b  illustrate logic to modify a configuration file with device parameters provided with a device driver in accordance with implementations of the invention. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0023]    In the following description, reference is made to the accompanying drawings which form a part hereof and which illustrate several embodiments of the present invention. It is understood that other embodiments may be utilized and structural and operational changes may be made without departing from the scope of the present invention.  
         [0024]    [0024]FIG. 1 illustrates a computing environment in which aspects of the invention are implemented. A computer system  2  is capable of communication with one or more Input/Output (I/O) devices  4   a  . . .  4   n , such as storage devices (e.g., disk drives, tape drives, optical disk drives, etc.), printers, display devices, or any other I/O device known in the art. The computer system  2  may communicate with the I/O devices  4   a  . . .  4   n  over a network (not shown), a direct connection (serial, cable, Universal Serial Bus (USB), Fire Wire, fiber optical wire, wireless, etc.), or the I/O devices  4   a  . . .  4   n  may be located in an Input/Output bay of the computer system  2  housing. The computer system  2  includes one or more application programs  6   a  . . .  6   n , which may comprise any application program known in the art (e.g., a database program, backup program, file management system program, etc.) and an operating system  8 . The computer system  2  may comprise any type of computing device known in the art, such as a workstation, desktop computer, server, mainframe, laptop, hand held computer, telephony device, etc.  
         [0025]    A plurality of device driver programs  10   a  . . .  10   n  are installed on the computer system  2 . Each device driver  10   a  . . .  10   n  includes driver parameters  12   a  . . .  12   n  that the device driver  10   a  . . .  10   n  uses when configuring and communicating device specific commands to the I/O devices  4   a  . . .  4   n  controlled by the device driver. The driver parameters  12   a  . . .  12   n  are provided, i.e., compiled, with the driver  10   a  . . .  10   n  and may be updated when the device driver  10   a  . . .  10   n  is updated. Further, associated with each different device driver  10   a  . . .  10   n  is a device configuration file  14   a  . . .  14   n  that maintains user entered settings. In implementations where the operating system  8  is the Unix operating system, the configuration files  14   a  . . .  14   n  would comprise the “.conf” files maintained to provide user entered parameters for the device drivers, such as the “st.conf” that provides parameters for tape drive drivers. In non-Unix implementations, the configuration file accessed by the device driver to obtain user entered settings may have a different format and naming convention.  
         [0026]    The described implementations provide a configuration utility program  20  that generates a graphical user interface (GUI)  22  through which the user may view and modify the parameter settings in the configuration files  14   a  . . .  14   n . The configuration utility program  20  maintains an association of parameter descriptors and parameter codes  24  (referred to herein as a “descriptor-code association  24 ”) that associates a human readable descriptor of each settable parameter with the parameter code, e.g., hexadecimal code, that is included in the configuration file  14   a  . . .  14   n . The descriptor-code association  24  may be maintained as a separate file or may be embedded in the configuration utility  20  or GUI  22  code.  
         [0027]    In one implementation, the configuration utility  20  may enable a user to manage and modify the configuration file (e.g., “st.conf”) for attached I/O devices  4   a  . . .  4   n  comprising tape drives. FIG. 2 illustrates an example of a GUI panel  50  generated by the configuration utility  20  to manage information on attached tape drives. The GUI panel  50  includes two selectable menu items labeled “Tape Drives”  52  and “Conf File”  54 . The panel in FIG. 2 shows the selectable controls displayed upon selection of the Tape Drives  52  menu item. The controls the user may select include:  
         [0028]    View Library of Supported Tape Drives  60 : causes the display of all manufacturers and models of tape drives that are supported by the installed tape driver.  
         [0029]    View Attached Tape Drives  62 : Displays the tape drive devices accessible to the computer system  2 . Such tape drive devices would have been determined by a previous issuance of an inquiry command, such as the Small Computer System Interface (SCSI) inquiry command in the case of SCSI tape drives.  
         [0030]    Issue Inquiry Command  64 : causes the issuance of an inquiry command, such as the SCSI inquiry command, to specific tape drives in order to determine if an individual or group of tape drives are accessible and/or attached.  
         [0031]    Determine Device Status  66 : issues a command, such as the “mt status” command to determine the current status of an individual or group of attached tape drives.  
         [0032]    Information on the attached SCSI drives that the configuration utility  20  makes available to the user would be maintained in a file used by the configuration utility  20 . Those skilled in the art will appreciate that alternative GUI mechanisms other than those shown in FIG. 2 may be used to invoke the commands  60 ,  62 ,  64 , and  66 . For instance, the commands  60 ,  62 ,  64 ,  66  may be listed in a drop down list displayed in response to selection of the displayed tape drives  50  menu item.  
         [0033]    [0033]FIG. 3 illustrates an example of a GUI interface  80  displayed in response to selection of the “Conf File” menu item  54  that enables a user to invoke certain configuration file  14   a  . . .  14   n  management operations. In GUI interface  80 , the operations the user may invoke to manage the tape drive configuration file (“st.conf”) may include:  
         [0034]    View Tape Drives in the Conf File  82 : Lists all the tape drives for which active settings are maintained in the configuration file  14   a  . . .  14   n.    
         [0035]    Add a Tape Drive to the Conf File  84 : Displays a further panel with user selectable settings for the tape device driver  10   a  . . .  10   n  to use.  
         [0036]    Remove a Tape Drive from the Conf File  86 : removes selected settings in the configuration file  14   a  . . .  14   n  for a specified tape drive by commenting out the selected settings.  
         [0037]    Error Check the Conf File  88 : Causes a routine to be performed to check the syntax of the statements in the configuration file  14   a  . . .  14   n  for any errors that could result in system failures.  
         [0038]    Write the Conf File  90 : In certain implementations, the configuration utility  20  makes a temporary copy in the computer  2  memory (not shown) of the configuration file to update. The user would harden the temporary copy and overwrite the tape configuration file  14   a  with the modified temporary copy by selecting the control  90 . In certain implementations, the error checking routine may be automatically performed be performing the write operation to ensure that there are no syntactical errors in the update to the configure file  14   a  . . .  14   n.    
         [0039]    Create a Custom Entry in the Conf File  92 : Allows the user to create a parameter not already predefined and selectable through the GUI  22 . This allows the user to add an association of a description to a parameter code.  
         [0040]    [0040]FIG. 4 illustrates an example of a GUI panel  100  that would be displayed to enable the user to enter settings for tape drive parameters in the device configuration file  4   a  . . .  4   bn , which would hold settings for multiple devices of a specific type. The panel  100  can be displayed in response to a user selecting a displayed tape drive from a GUI panel displayed in response to selection of the “View Attached Tape Drives” control  62  in GUI panel  80  (FIG. 3). The parameters displayed in the GUI panel  100  comprise a human readable description of parameter codes that may be included in the tape drive configuration file  14   a  (“st.conf”). As discussed, the descriptor-code association  24  maintains the association of a human readable description and the parameter code, which may comprise a hexadecimal code or other non-descriptive string. Panel  100  displays parameters the user may select to include in the configuration file  14  for tape drive ABC. The human discernible parameters listed in GUI panel  100  that maybe selected to include as an active parameter for tape drive ABC in the configuration file  14  include, by way of example:  
         [0041]    ST VARIABLE: indicates whether the tape device supports variable length record sizes.  
         [0042]    ST QIC: indicates a Quarter Inch Cartridge (QIC) tape device.  
         [0043]    ST REEL: indicates a one-half inch reel tape device.  
         [0044]    ST BSF: indicates whether the device supports backspace over end-of-file (EOF) marks.  
         [0045]    ST BSR: indicates whether the tape device supports the backspace record (BSR) operation If the device does not support BSR, then the tape driver  10  may emulate the action by rewinding the tape and using the forward space record operation to forward the tape to the correct file. The driver then uses forward space record to forward the tape to the correct record.  
         [0046]    ST LONG ERASE: indicates whether the tape device needs a longer time than normal to erase.  
         [0047]    ST AUTODEN OVERRIDE: auto-density override flag. Indicates whether the device is capable of determining the tape density automatically without issuing a “mode-select”/“mode-sense command”.  
         [0048]    ST NOBUF: indicates the ability of the tape drive to perform buffered writes. A buffered write occurs when the device acknowledges the completion of a write request after the data has been written to the tape drive buffer, but before all of the data has been written to the tape.  
         [0049]    ST SOFT ERROR REPORTING: indicates whether the tape device will perform a “request sense” or “log sense” command when the device is closed. Currently, only Exabyte and DAT drives support this feature.  
         [0050]    ST LONG TIMEOUTS: indicates whether the tape device requires timeouts that are five times longer than usual for normal operation.  
         [0051]    ST BUFFERED WRITES: indicates whether data is buffered by the tape drive device when data is written to the tape device. The application  6   a ,  6   b  . . .  6   n  may receive acknowledgment of completion of the write request before the data has been written to tape.  
         [0052]    The above described tape drive parameters the user may set through the GUI panel  100  are for illustrative purpose, and additional, different or fewer parameters may be provided. The GUI panel  100  further displays a “Done” button  102  which closes the GUI panel  100  and returns the user to a previous panel. The changes made to the tape configuration file  14   a  would remain in the temporary file in computer  2  memory until the user selects the “Write the Conf File” control  90  (FIG. 3) to replace the tape configuration file  14   a  with the temporary version including the modifications. Alternatively, the user can select the “Future Use” control  106  to save the modified configuration file  14   a  on disk until the user selects the “Write the Conf File” control  90 .  
         [0053]    [0053]FIGS. 5 a ,  5   b , and  5   c  and  6  illustrate logic implemented in the configuration utility  20  to perform operations requested by the user through the GUI  22 . With respect to FIG. 5 a , in response to user selection of “View Library of Supported Tape Drives” control  60  (FIG. 2) (at block  150 ), the configuration utility  20  accesses (at block  152 ) information from the tape drive on the list of devices that have their support compiled into the device driver  10   a , such as through the driver parameters  12   a . The information on the tape drives supported by the device driver  10   a  is then displayed (at block  154 ).  
         [0054]    With respect to FIG. 5 b , in response to user selection of the “View Attached Tape Drives” control  62  (FIG. 2) (at block  160 ), the configuration utility  20  queries (at block  162 ) attached devices using an inquiry command, such as the SCSI inquiry command, to determine the attached tape drives and then displays (at block  164 ) information thereon.  
         [0055]    With respect to FIG. 5 c , in response to receiving user selection of the “Remove a Tape Drive from the Conf File” control  86  (FIG. 3), the configuration utility  20  accesses the active entries in the device configuration file  14   a  and comments them out so they are no longer active and accessible to the tape driver  14   a.    
         [0056]    [0056]FIG. 6 illustrates logic implemented in the configuration utility  20  to enable the user to modify the parameter settings in the device configuration file  14   a  (“st.conf”). Control begins at block  200  upon receiving a request to modify the configuration file  14   a , which may comprise selection of a tape drive displayed in the GUI  22 . The GUI panel  100  (FIG. 4) including the selectable tape drive settings is displayed (at block  202 ). The configuration utility  20  then creates (at block  204 ) a temporary copy of the configuration file  14   a  in the computer system memory (not shown) to which changes can be made before hardening in the device configuration file  14   a . This allows the user to cancel the changes or save them in a yet further file to avoid effecting the current settings.  
         [0057]    When the user selects (at block  206 ) the “Done” button  102 , the configuration utility  20  scans (at block  208 ) the GUI panel  100  to determine any parameter check boxes the user may have selected. If (at block  210 ) the user has selected parameters displayed in the GUI panel  100 , then the configuration utility  20  performs a loop at blocks  212  through  218  for each user selected parameter. For each user selected parameter, the configuration utility  20  determines (at block  214 ) the code from the descriptor-code association  24  corresponding to the selected entry. The configuration utility  20  then writes the determined code, e.g., the hexadecimal code, to the temporary configuration file in memory to the section in the configuration file providing parameters for the selected tape drive. In writing the code, the configuration utility  20  would conform to the syntactical requirements of the configuration file. After updating the temporary configuration file with the codes for the user selected parameters, the configuration utility  20  returns (at block  220 ) to display the main tape drive GUI panel  80  (FIG. 2). Alternatively, if (at block  210 ) the user has not selected any parameters for the selected tape drive displayed in the main tape drive GUI panel  80 , then control also proceeds to block  220  to return to the main tape drive GUI panel  80 . Upon receiving (at block  222 ) user selection of the “Write the Conf File” control  90  (FIG. 3), the configuration utility  20  hardens the temporary configuration file in the computer  2  memory to the device configuration file  14   a  to apply the parameter selections the user made.  
         [0058]    [0058]FIGS. 7 and 8 illustrate the GUI panels displayed to allow the user to specify the configuration of attached SCSI devices. FIG. 7 illustrates a Target/Logical Unit Number (LUN) admin GUI panel  250  displayed in response to selection of the Target/LUN admin  56  menu item from any of the panels  50 ,  80 ,  100 . The Target/LUN admin GUI panel  250  is used to manage the assignment of a target number defining the location of a specific device, identified by LUN number and name, in a chain of devices, such as a SCSI chain. In GUI interface  250 , the operations the user may invoke to manage the assignment of target numbers to devices comprises:  
         [0059]    View Target/LUN Binding Info in Conf File  252 : Accesses the assignment of target numbers to devices, identified by name and LUN, that is maintained in the device configuration file  14   a  . . .  14   n . After reviewing this information, unused ports can be removed from the list in the configuration file  14   a  . . .  14   n  to improve boot time performance by eliminating the requirement that the computer scan unused ports during the boot process. The list informs the computer which ports to scan. If a device is present on a port, but the computer does not scan the device, then such bypassed device would not be listed as part of the device tree for the computer. On the other hand if all the ports are listed, but most of the ports do not have a device attached, then the computer has to wait for the inquiry to timeout for each of the ports that do not have attached devices, which significantly increases the boot time. For these reasons, providing a list of used ports in the device configuration file  14   a  . . .  14   n  to check during initialization substantially reduces the time required for initialization.  
         [0060]    Add a Target/LUN Binding to the Conf File  254 : Selection displays a further GUI panel, shown as panel  280  in FIG. 8, in which the user may enter the assignment of a target number to a device, identified by name and LUN.  
         [0061]    Remove a Target/LUN Binding to the Conf File  256 : selection comments-out the target number assignment for the selected device in the configuration file  14   a.    
         [0062]    [0062]FIG. 8 illustrates an add target/LUN binding window  280  in which the user may enter a target number for a specific device, identified by the device name LUN number, and device class, e.g., SCSI. Selecting “Done”  282  adds the target/LUN binding information entered in the window  280  into the tape configuration file  14   a  for use during initialization when detecting devices in a chain, such as a SCSI chain, where each device in the chain connects to another device to form a loop of devices. Additionally, the user interface may allow entry of information for attached devices in alternative formats, such as devices in a Fibre Channel Arbitrated Loop or other loop technology.  
         [0063]    With the described implementations and user interface, the user may modify the configuration file without having to manually edit the contents of the configuration file. This will prevent the user from entering syntactical mistakes or incorrect information. Restricting users in this manner reduces those operational problems that frequently result from user entered mistakes in the configuration file  14   a  . . .  14   n . In turn, the number of customer service calls placed to customer support to troubleshoot problems related to user editing mistakes in the configuration file would further be reduced, thereby reducing the cost of customer service.  
       Accessing the Device Drivers  
       [0064]    As discussed, the configuration utility  20  communicates with the device driver  10   a  . . .  10   n  when performing various configuration related operations. FIG. 9 illustrates further details of FIG. 1 including a shared library  30  of Application Programming Interfaces (API)  32  called by the configuration utility  20  and/or GUI  22  to communicate with the device drivers  10   a  . . .  10   n  in order to access information and configure the device drivers  10   a  . . .  10   n . In certain UNIX implementations, the APIs include calls  34  to IOCTLs  36 , which are device control programs used to access a device driver. The IOCTLs  36  take as parameters a file descriptor associated with a specific device that uses the device driver program and a control function. In alternative implementations, the APIs  32  may include calls  34  to other types of program interfaces to interact with the device drivers  10   a  . . .  10   n  or, alternatively, include code to communicate directly with the device drivers  14   a ,  14   b  . . .  14   n . Both the GUI  22  or configuration utility  20  may call the APIs  32  in the shared library  30  to access functionality to interact with the device drivers  10   a  . . .  10   n.    
         [0065]    In implementations where the configuration utility  20  and GUI  22  are coded using the Java programming language, the APIs  32  may be written in the C or C++ programming language. In such implementations, the configuration utility  20  and GUI  22  would use the Java Native Interface to access the functionality of the APIs  32 .  
       Updating Device Drivers  
       [0066]    In the implementation of FIG. 1, the driver parameters  12   a  . . .  12   n  available to the device drivers  10   a  . . .  10   n  may be compiled into the device driver  10   a  . . .  10   n . In such implementations, updates to the driver parameters  12   a  . . .  12   n  are provided in the form of an update to the entire device driver program  10   a  . . .  10   n . FIG. 10 illustrates an alternative implementation of the computer system  302  where the driver parameters  312   a  . . .  312   n  are maintained in a file separate from the device driver programs  310   a  . . .  310   n . In such implementations, the driver parameters  312   a  . . .  312   n  may be updated separately from the device driver programs  310   a  . . .  310   n  because the driver parameters  312   a  . . .  312   n  are maintained in a separate file. The implementation of FIG. 10 may include a shared library, such as the shared library  30  shown in FIG. 9, including APIs to enable communication with the device drivers  310   a  . . .  310   n . The device drivers  310   a  . . .  310   n  would execute IOCTL functions defined for the called API to perform the requested operations with respect to driver parameters  312   a  . . .  312   n.    
         [0067]    In certain implementation of FIG. 10, updates to the device driver may only involve an update to the driver parameters  312   a  . . .  312   n , and no other components such as the device configuration file  314   a  . . .  314   n  or device driver  310   a  . . .  310   n  code. In such cases, the updates would not affect the current device configuration file  314   a  . . .  314   n  or disturb any user settings specified therein.  
         [0068]    The GUI  322  may display panels to enable the user to review the parameters supported in the driver parameters  312   a  . . .  312   n  and copy any such supported parameters over to the device configuration file  314   a  . . .  314   n . For instance, in the GUI panel  50  in FIG. 2 the user may select the “View Library of Supported Tape Drives” control  60  to view a list of supported tape drivers. In response to selecting one of the displayed tape drivers supported by the tape driver  310   a , the configuration utility  320  may then display GUI panel  330  shown in FIG. 11, which displays the tape parameters  332  available in the driver parameter  312   a  file for the selected tape drive. The user may select the parameters displayed in the GUI panel  330  to copy over to the tape configuration file  314   a . When accessing the parameters supported in a driver parameter  312   a  . . .  312   n  file, the GUI  322  or configuration utility  320  would issue the shared library APIs to have the device driver  310   a  . . .  310   n  interact with the driver parameters  312   a  . . .  312   n  to access the requested information in response to executing the IOCTL functions associated with the called API.  
         [0069]    [0069]FIGS. 12 a  and  12   b  illustrate logic implemented in the configuration utility  320  or GUI  322  to copy driver parameters  312   a  . . .  312   n  for a device driver  310   a  . . .  310   n  to a device configuration file  314   a  . . .  314   n . The logic of FIGS. 12 a  and  12   b  is described with respect to copying tape drive parameters, referred to as tape parameters  312   a , to a tape configuration file (st.conf), referred to as tape configuration file  314   a . However, the logic of FIGS. 12 a  and  12   b  may apply to copying device parameters for I/O devices other than a tape drive. Control begins at block  350  upon receiving user selection of a tape device in the panel displayed in response to selection of the “View Library of Supported Tape Drives” control  60  (FIG. 2). In response, the configuration utility  320  (or GUI  322 ) calls (at block  352 ) an API  32  (FIG. 8) in the shared library  30 , which in turn calls IOCTL functions  36 , to query the tape driver  310   a  for the tape parameters  312   a  for the selected tape drive. Upon receiving (at block  354 ) the tape parameters from the queried tape driver, a panel  330  (FIG. 11) is displayed (at block  356 ) with the received parameters  332  and checkboxes to allow the user to select any of the displayed parameters  332 . Upon receiving (at block  358 ) user selection of the “Done” button  334 , the configuration utility  320  scans (at block  360 ) the GUI panel  330  parameter checkboxes  332  to determine which boxes were checked by the user. If (at block  362 ) the user did not select any of the parameter checkboxes  332 , then the main tape drive page  50  (FIG. 2) or some other page is displayed (at block  364 ).  
         [0070]    If (at block  362 ) the user did select one or more of the displayed parameter checkboxes  332 , then the tape configuration file  314   a  (st.conf) is copied (at block  370 ) to computer  302  memory (not shown). If (at block  372  in FIG. 12 b ) there is no active entry in the copy of the configuration file  314   a  for the selected tape drive, then the configuration utility  320  (or GUI  322 ) adds (at block  376 ) an entry in the memory copy of the tape configuration file  314   a  for the selected tape driver. From block  376  or the yes branch of  372 , a loop is performed at blocks  378  through  384  for each user selected parameter (checkbox) in the GUI panel  330  (FIG. 11). For each user selected parameter, the code for the selected parameter in the driver parameters  312  is determined (at block  380 ). The code may be accessed directly from the driver parameter file  312   a  or, if the parameter is known, then the code may be determined from the descriptor-code association  324  corresponding to the selected parameter. The code is then written (at block  382 ) to the location in the temporary configuration file  314   a  for the selected tape drive entry thereby overwriting any previously set value for the selected parameter if there is such a previously set value. If there are further user selected parameters, then control proceeds (at block  384 ) back to block  378  to write the code for the next user selected parameter.  
         [0071]    The result of the operations of FIGS. 12 a  and  12   b  is that parameter values maintained in the driver parameters  312   a  . . .  312   n  used by the device drivers  310   a  . . .  310   n  are selectively copied over to the configuration file  314   a  . . .  314   n . In this way, the user may select specific parameters provided with the device driver to include in the configuration file with the parameters the user is creating for the device.  
       Additional Implementation Details  
       [0072]    The described configuration utility may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” as used herein refers to code or logic implemented in hardware logic (e.g., an integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), etc.) or a computer readable medium, such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.). Code in the computer readable medium is accessed and executed by a processor. The code in which preferred embodiments are implemented may further be accessible through a transmission media or from a file server over a network. In such cases, the article of manufacture in which the code is implemented may comprise a transmission media, such as a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention, and that the article of manufacture may comprise any information bearing medium known in the art.  
         [0073]    In certain implementations, a single configuration utility program may provide a user interface to manage and modify configuration files for multiple device types and device drivers or for only a single device type.  
         [0074]    In the described implementations, the user interface presented by the configuration utility comprised a graphical user interface (GUI) that the user manipulates using any input device known in the art, such as a keyboard, mouse pointer, pen stylus, touch screen having comprising a display device with a touch-sensitive transparent panel, microphone for receiving voice activated commands, etc. Additionally, the user interface may comprise an audio output and input device, where the audio output device generates audio output that inform the user of the configuration options and the audio input device receives audio signals from the user to select user interface options and settings for the configuration file.  
         [0075]    The program flow logic described in the flowcharts indicates certain events occurring in a certain order. Those skilled in the art will recognize that the ordering of certain programming steps or program flow may be modified without affecting the overall operation performed by the preferred embodiment logic, and such modifications are in accordance with the preferred embodiments.  
         [0076]    The foregoing description of the preferred embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.