NeXTSTEPDRIVERKIT:Chapter1 6

From 흡혈양파의 번역工房
Revision as of 17:26, 8 October 2017 by Onionmixer (talk | contribs) (NeXTSTEP DRIVER KIT IODevice 객체 생성 방법 영문 내용 추가)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
How IODevice Objects are Created

IODevice 객체 생성 방법

Drivers are packaged into driver bundles. A driver bundle contains its relocatable code and configuration information—everything needed to load and configure the driver. It may also contain help information, programs to be run before and after loading the driver, and a configuration inspector that the Configure application uses to access configuration data. Chapter 4, "Building, Configuring, and Debugging Drivers," tells you more about bundle contents and how to create a driver bundle.


When the system starts up, it goes through three steps to create each driver object, using the information in the driver bundle:

  1. Load the relocatable code for the driver.
  2. Create an IODeviceDescription object for the device.
  3. Send a probe: message to the IODevice class object to instantiate a driver object.


The system goes through two phases of driver creation. In the first phase, it performs these three steps to create all the boot device drivers. Boot drivers are the drivers that must be loaded before the kernel can be active, such as the driver for the boot device. In the second phase, the system creates the active device drivers—drivers for the rest of the devices in the system. The System.config/Instance0.table file defines the boot and active devices.


Some driver objects need to know about each other. For instance, an indirect driver controlling a SCSI peripheral needs to communicate with the direct driver that manages the SCSI controller. These drivers get connected with each other during the startup process. See "Connecting the Driver," in Chapter 2, "Designing a Driver."


The system is not limited to creating drivers only at system start up time. You can also load a driver after the system has started up with the driverLoader command. See "Using the driverLoader Command" in Chapter 4, "Building, Configuring, and Debugging Drivers," for more information.


Loading Driver Relocatable Code

In the first phase of driver object creation, the kernel loads the driver's relocatable code (in the file Driver_reloc in the driver bundle, where Driver is the driver's name) if necessary. The driver is already loaded if it's in the kernel. If there are multiple instances of the driver, the relocatable code is loaded only once.


Creating a Device Description

Next, the kernel creates an IOConfigTable object that provides methods to examine the appropriate configuration file for the driver (either Default.table or Instancen.table). The IOConfigTable object parses the configuration information it gets, which is in configuration key/value pairs in this file. From this information, the kernel instantiates an IODeviceDescription object, which encapsulates information about the driver.


The driver's bus type is indicated in the configuration table as the value associated with the "Bus Type" configuration key (see "Configuration Keys" in the Appendix). The kernel creates the appropriate IODeviceDescription object for the bus:

  • Bus Type
    • IODevice Description Subclass
  • EISA, ISA, VL-Bus
    • IOEISADeviceDescription
  • PCI
    • IOPCIDeviceDescription
  • PCMCIA
    • IOPCMCIADeviceDescription


IOPCIDeviceDescription and IOPCMCIADeviceDescription are subclasses of IOEISADeviceDescription, which is a subclass of IODeviceDescription.


After instantiating the IODeviceDescription object, the kernel may do further initialization, using methods in IODeviceDescription to get configuration information. For example, for a PCI-bus device, the kernel might check whether the location of the object on the bus is correct, and if it isn't, the kernel doesn't initialize that device.


If the system supports automatic detection of devices, it automatically scans all system buses to determine which devices are present and to obtain additional configuration information. For more information, see "Auto Detection of Devices" in "Other Features" of Chapter 5, "Reference." Some EISA- and PCI-based systems support this feature.


For more information on configuration tables, see Chapter 4.


Instantiating Drivers

The kernel invokes probe:, a class method in the IODevice class, to instantiate a driver. You must override this method in your driver.


The receiver of a probe: message determines whether to create a new instance of itself, with the help of information passed as the probe: message's argument—the IODeviceDescription object created in the previous step. The IODeviceDescription object contains information about the device's logical location in the system, and the device can query this object for additional information about the way it is configured. From this information, probe: can determine whether the device exists. If the device is present, probe: instantiates and initializes the driver. Your probe: method should invoke the initFromDeviceDescription: method, which initializes the driver.


Note: Use the alloc and initFromDeviceDescription: methods to instantiate and initialize the driver, not the new method.


If probe: creates a driver instance, it returns YES. Otherwise, it returns NO.

Note: Declare your probe: method to return BOOL—not id.