NeXTSTEPDRIVERKIT:Chapter4 2

Configuring Drivers

드라이버 설정하기(Configuring Drivers)

After you have built your driver, you need to configure it with the Configure application.

Configure Application

You can configure devices and add drivers with the Configure application. When you select a device, Configure loads the device's inspector, which provides a user interface for manipulating the device configuration (choosing its DMA channels, for example). If you don't supply a device inspector for your driver, Configure uses a default device inspector. See the IODeviceInspector class and IOConfiguration protocol specifications for more information on device inspectors.

The Configure application reads the key/value pairs from a driver bundle's Default.table and displays them in a Configuration Inspector Panel. The user interface allows the user to change the displayed parameters and warns of possible value conflicts. When the user finishes modifying the configuration, Configure writes the updated configuration to the indicated Instancen.table and configures the driver based on the information in the configuration and kernel tables.

When the system starts up, the kernel uses an IOConfigTable object to parse the configuration information in the Instancen.table. From this information, the kernel instantiates an IODeviceDescription object, which encapsulates information about the driver. The kernel passes the IODeviceDescription object as the parameter to the probe: method, which instantiates the driver object based on this information.

There's a list of standard key/value configuration pairs in the "Configuration Keys" section in the Appendix.

---

How Configuring Kernel-Level Driver Kit Drivers Differs from Configuring Other Loadable Kernel Servers

The configuration of Driver Kit kernel-level drivers differs from that of other Loadable Kernel Servers (LKSs) in the following ways:

• Each Driver Kit driver has its own configuration directory under /NextLibrary/Devices. Other LKSs have no standard way of getting configuration information.
  
• With the Configure application, users can add Driver Kit drivers to the system, as well as specify configuration information for each driver. Other LKSs are generally added to the system by adding a line to /etc/kern_loader.conf.
  
• Driver Kit drivers are allocated and loaded with the driverLoader command, which uses the information in the driver's configuration directory. You can load an LKS with the kernel-server utility, kl_util, but it doesn't cause the driver to be probed.
  
• Driver Kit drivers can't currently be unloaded, unlike other LKSs. For example, if you want to change a driver that's already running, you must restart the system to be able to load the new driver.
  

---

Writing a Custom Inspector

The Configure application uses inspectors to configure a driver. With the default inspector in Configure, you can configure values that belong to the standard set of keys with no further implementation effort. If you've added custom parameters, however, you need to implement a custom inspector to view and modify them.

You have two choices in implementing a custom inspector:

• Add an accessory view to the inspector, with an 80-pixel height limit.
  
• Replace the standard inspector completely. You're still limited to a 640480 view. However, you can use a button to display a panel if you run out of space.
  

You implement an inspector by creating a subclass of IODeviceInspector. For example, you can create a subclass of IODisplayInspector (a subclass of IODeviceInspector) to implement a display inspector. For an example, study the inspector in /NextLibrary/Documentation/NextDev/Examples/DriverKit/DriverInspector.

Other classes relevant to creating an inspector include IOAddressRanger, IODeviceDescription, IODeviceMaster, and IOEISADeviceDescription. Some of these classes adopt the IOConfigurationInspector protocol.

Creating an Inspector

Override the following methods in the IODeviceInspector class and the IOConfigurationInspector protocol:

• init. Find and load the nib file that contains the accessory view using the bundle for your inspector. Initialize the user interface and find your driver.
  
• inspectionView. Override this if you're replacing the standard inspector.
  
• setTable:. Invoke the superclass's implementation:
  

  * [super setTable:]
  

  Invoke setAccessoryView: to specify and initialize the accessory View. Initialize the user interface settings from the table being inspected.
  
• resourcesChanged:. Update the user interface in response to resources being chosen or dropped in the inspector.
  

Modifying Custom Parameters

Implement a set of target/action methods to change the custom parameters. The user interface elements of the inspector invokes these methods. Convert the new parameter state to an appropriate string value for display, and insert it into the inspected table with insertKey:value:. The key must be a unique string, and you can use the NXUniqueString() function to generate a unique key based on the string argument. The value should be a copy--use NXCopyStringBuffer() to copy it:

[table insertKey:key value:NXCopyStringBuffer(value)];

Changing Driver Parameters with IODeviceMaster

Besides Configure, another way to change parameters associated with a driver is through the IODeviceMaster class, which provides access to a driver instance. First, find your driver using the lookUpByDeviceName:objectNumber:deviceKind: method. Then manipulate parameters associated with that instance with these methods:

• getCharValues:forParameter:objectNumber:count:
• setCharValues:forParameter:objectNumber:count:
• getIntValues:forParameter:objectNumber:count:
• setIntValues:forParameter:objectNumber:count:

Active driver values should be displayed in the user interface--even if they differ from the current configuration table values. If you want the values you change to persist beyond the time the system is powered off or restarted, you must write them to the configuration table.