| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Chapter 3Reading and Writing Data in Kernel MemoryIn this chapter, you will extend the very simple prototype driver you developed in the previous chapter. The driver you will develop in this chapter displays data read from kernel memory. The first version of this driver writes data to a system log every time the driver is loaded. The second version of this driver displays data at user request. In the third version of this driver, the user can write new data to the device. Displaying Data Stored in Kernel MemoryThe pseudo device driver presented in this section writes a constant string to a system log when the driver is loaded. This first version of the Quote Of The Day driver (qotd_1) is even more simple than the dummy driver from the previous chapter. The dummy driver includes all functions that are required to drive hardware. This qotd_1 driver includes only the bare minimum functions it needs to make a string available to a user command. For example, this qotd_1 driver has no cb_ops(9S) structure. Therefore, this driver defines no open(9E), close(9E), read(9E), or write(9E) function. If you examine the dev_ops(9S) structure for this qotd_1 driver, you see that no getinfo(9E), attach(9E), or detach(9E) function is defined. This driver contains no function declarations because all the functions that are defined in this driver are declared in the modctl.h header file. You must include the modctl.h header file in your qotd_1.c file. This qotd_1 driver defines a global variable to hold its text data. The _init(9E) entry point for this driver uses the cmn_err(9F) function to write the string to a system log. The dummy driver also uses the cmn_err(9F) function to display messages. The qotd_1 driver is different from the dummy driver because the qotd_1 driver stores its string in kernel memory. Writing Quote Of The Day Version 1Enter the source code shown in the following example into a text file named qotd_1.c. Example 3-1 Quote Of The Day Version 1 Source File
Enter the configuration information shown in the following example into a text file named qotd_1.conf. Example 3-2 Quote Of The Day Version 1 Configuration File
Building, Installing, and Using Quote Of The Day Version 1Compile and link the driver. Use the -D_KERNEL option to indicate that this code defines a kernel module. The following example shows compiling and linking for a 32-bit architecture using the Sun Studio C compiler:
Note that the name of the driver, qotd_1, must match the name property in the configuration file. Make sure you are user root when you install the driver. Copy the driver binary to the /tmp directory as discussed in Device Driver Testing Tips.
Copy the configuration file to the kernel driver area of the system.
This qotd_1 driver writes a message to a system log each time the driver is loaded. The cmn_err(9F) function writes low priority messages such as the message defined in this qotd_1 driver to /dev/log. The syslogd(1M) daemon reads messages from /dev/log and writes low priority messages to /var/adm/messages. To test this driver, watch for the message in /var/adm/messages. In a separate window, enter the following command:
Make sure you are user root when you load the driver. Use the add_drv(1M) command to load the driver:
You should see the following messages in the window where you are viewing /var/adm/messages:
This last line is the content of the variable output by the cmn_err(9F) function in the _init(9E) entry point. The _init(9E) entry point is called when the driver is loaded. Displaying Data on DemandThe sample code in this section creates a pseudo device that is controlled by the driver. The driver stores data in the device and makes the data available when the user accesses the device for reading. This section first discusses the important code differences between these two versions of the Quote Of The Day driver. This section then shows you how you can access the device to cause the quotation to display. Writing Quote Of The Day Version 2The driver that controls the pseudo device is more complex than the driver shown in the previous section. This section first explains some important features of this version of the driver. This section then shows all the source for this driver. The following list summarizes the differences between the two versions of the Quote Of The Day driver:
The following sections provide more detail about the additions and changes in Version 2 of the Quote Of The Day driver. Managing Device StateThe _init(9E) and _fini(9E) entry points and all six new entry points defined in this driver maintain a soft state for the device. Most device drivers maintain state information with each instance of the device they control. An instance usually is a sub-device. For example, a disk driver might communicate with a hardware controller device that has several disk drives attached. See "Retrieving Driver Soft State Information" in Writing Device Drivers for more information about soft states. This sample driver allows only one instance. The instance number is assigned in the configuration file. See Example 3-4. Most device drivers allow any number of instances of a device to be created. The system manages the device instance numbers, and the DDI soft state functions manage the instances. The following flow gives an overview of how DDI soft state functions manage a state pointer and the state of a device instance:
The ddi_soft_state_zalloc(9F), ddi_get_soft_state(9F), and ddi_soft_state_free(9F) functions coordinate access to the underlying data structures in a way that is safe for multithreading. No additional locks should be necessary. Initializing and UnloadingThe _init(9E) entry point first calls the ddi_soft_state_init(9F) function to initialize the soft state. If the soft state initialization fails, that error code is returned. If the soft state initialization succeeds, the _init(9E) entry point calls the mod_install(9F) function to load a new module. If the module install fails, the _init(9E) entry point calls the ddi_soft_state_fini(9F) function and returns the error code from the failed module install. Your code must undo everything that it does. You must call ddi_soft_state_fini(9F) if the module install fails because the _init(9E) call succeeded and created a state pointer. The _fini(9E) entry point must undo everything the _init(9E) entry point did. The _fini(9E) entry point first calls the mod_remove(9F) function to remove the module that the _init(9E) entry point installed. If the module remove fails, that error code is returned. If the module remove succeeds, the _fini(9E) entry point calls the ddi_soft_state_fini(9F) function to destroy the state pointer and the state structures for all instances of this device. Attaching and DetachingThe attach(9E) entry point first calls the ddi_get_instance(9F) function to retrieve the instance number of the device information node. The attach(9E) entry point uses this instance number to call the ddi_soft_state_zalloc(9F), ddi_get_soft_state(9F), and ddi_create_minor_node(9F) functions. The attach(9E) entry point calls the ddi_soft_state_zalloc(9F) function to create a state structure for this device instance. If creation of the soft state structure fails, attach(9E) writes an error message to a system log and returns failure. This device instance is not attached. If creation of the soft state structure succeeds, attach(9E) calls the ddi_get_soft_state(9F) function to retrieve the state structure for this device instance. If retrieval of the state structure fails, attach(9E) writes an error message to a system log, calls the ddi_soft_state_free(9F) function to destroy the state structure that was created by ddi_soft_state_zalloc(9F), and returns failure. This device instance is not attached. If retrieval of the state structure succeeds, attach(9E) calls the ddi_create_minor_node(9F) function to create the device node. At the top of this driver source file, a constant named QOTD_NAME is defined that holds the string name of the device. This constant is one of the arguments that is passed to ddi_create_minor_node(9F). If creation of the device node fails, attach(9E) writes an error message to a system log, calls the ddi_soft_state_free(9F) function to destroy the state structure that was created by ddi_soft_state_zalloc(9F), calls the ddi_remove_minor_node(9F) function, and returns failure. This device instance is not attached. If creation of the device node succeeds, this device instance is attached. The attach(9E) entry point assigns the instance number that was retrieved with ddi_get_instance(9F) to the instance member of the state structure for this instance. Then attach(9E) assigns the dev_info structure pointer that was passed in the attach(9E) call to the dev_info structure pointer member of the state structure for this instance. The ddi_report_dev(9F) function writes a message in the system log file when the device is added or when the system is booted. The message announces this device as shown in the following example:
The detach(9E) entry point first calls the ddi_get_instance(9F) function to retrieve the instance number of the device information node. The detach(9E) entry point uses this instance number to call the ddi_soft_state_free(9F) function to destroy the state structure that was created by ddi_soft_state_zalloc(9F) in the attach(9E) entry point. The detach(9E) entry point then calls the ddi_remove_minor_node(9F) function to remove the device that was created by ddi_create_minor_node(9F) in the attach(9E) entry point. Opening the Device, Closing the Device, and Getting Module InformationThe open(9E) and close(9E) entry points are identical in this sample driver. In each case, the entry point first calls the getminor(9F) function to retrieve the minor number of the device. Then each entry point uses this instance number to call the ddi_get_soft_state(9F) function to retrieve the state structure for this device instance. If no state structure is retrieved, an error code is returned. If a state structure is retrieved, the open(9E) and close(9E) entry points both verify the type of this device. If this device is not a character device, the EINVAL (invalid) error code is returned. If the user wants device information for this device instance, the getinfo(9E) entry point returns the device information from the state structure. If the user wants the instance number of this device instance, the getinfo(9E) entry point uses the getminor(9F) function to return the minor number. Reading the DataThe read(9E) entry point first calls the getminor(9F) function to retrieve the minor number of the device. The read(9E) entry point uses this instance number to call the ddi_get_soft_state(9F) function to retrieve the state structure for this device instance. If no state structure is retrieved, read(9E) returns an error code. If a state structure is retrieved, read(9E) calls the uiomove(9F) function to copy the quotation from the driver to the uio(9S) I/O request structure. Checking Data ValidityVersion 2 of the driver uses ASSERT(9F) statements to check the validity of data. If the asserted expression is true, the ASSERT(9F) statement does nothing. If the asserted expression is false, the ASSERT(9F) statement writes an error message to the console and causes the system to panic. To use ASSERT(9F) statements, include the sys/debug.h header file in your source and define the DEBUG preprocessor symbol. If you do not define the DEBUG preprocessor symbol, then the ASSERT(9F) statements do nothing. Simply recompile to activate or inactivate ASSERT(9F) statements. Quote Of The Day Version 2 SourceEnter the source code shown in the following example into a text file named qotd_2.c. Example 3-3 Quote Of The Day Version 2 Source File
Enter the configuration information shown in the following example into a text file named qotd_2.conf. Example 3-4 Quote Of The Day Version 2 Configuration File
Building, Installing, and Using Quote Of The Day Version 2Version 2 of the driver uses ASSERT(9F) statements to check the validity of data. To use ASSERT(9F) statements, include the sys/debug.h header file in your source and define the DEBUG preprocessor symbol. Compile and link the driver. If you use ASSERT(9F) statements to check the validity of data, you must define the DEBUG preprocessor symbol:
The following example shows compiling and linking for a 32-bit architecture if you are not using ASSERT(9F) statements:
Make sure you are user root when you install the driver. Copy the driver binary to the /tmp directory as discussed in Building and Installing the Template Driver.
Copy the configuration file to the kernel driver area of the system.
In a separate window, enter the following command:
Make sure you are user root when you load the driver. Use the add_drv(1M) command to load the driver:
You should see the following messages in the window where you are viewing /var/adm/messages:
When this version of the Quote Of The Day driver loads, it does not display its quotation. The qotd_1 driver wrote a message to a system log through its _init(9E) entry point. This qotd_2 driver stores its data and makes the data available through its read(9E) entry point. You can use the modinfo(1M) command to display the module information for this version of the Quote Of The Day driver. The module name is the value you entered for the second member of the modldrv structure. The value 96 is the major number of this module.
This driver also is the most recent module listed by prtconf(1M) in the pseudo device section:
When you access this qotd_2 device for reading, the command you use to access the device retrieves the data from the device node. The command then displays the data in the same way that the command displays any other input. To get the name of the device special file, look in the /devices directory:
This output shows that qotd_2@0:qotd is a character device. This listing also shows that only the root user has permission to read or write this device. Make sure you are user root when you test this driver. To test the qotd_2 driver, you can use the more(1) command to access the device file for reading:
Modifying Data Stored in Kernel MemoryIn this third version of the Quote Of The Day driver, the user can write to the data that is stored in kernel memory. The pseudo device that is created in this section is a pseudo-disk device or ramdisk device. A ramdisk device simulates a disk device by allocating kernel memory that is subsequently used as data storage. See ramdisk(7D) for more information about ramdisk devices. As in Version 2 of the Quote Of The Day driver, this Version 3 driver stores its data and makes the data available through its read(9E) entry point. This Version 3 driver overwrites characters from the beginning of the data when the user writes to the device. This section first discusses the important code differences between this version and the previous version of the Quote Of The Day driver. This section then shows you how you can modify and display the quotation. In addition to changes in the driver, Quote Of The Day Version 3 introduces a header file and an auxiliary program. The header file is discussed in the following section. The utility program is discussed in Using Quote Of The Day Version 3. Writing Quote Of The Day Version 3This third version of the Quote Of The Day driver is more complex than the second version because this third version enables a user to change the text that is stored in the device. This section first explains some important features of this version of the driver. This section then shows all the source for this driver, including the header file and the configuration file. The following list summarizes the new features in Version 3 of the Quote Of The Day driver:
The following sections provide more detail about the additions and changes in Version 3 of the Quote Of The Day driver. The dev_ops(9S) structure and the modlinkage(9S) structure are the same as they were in Version 2 of the driver. The modldrv(9S) structure has not changed except for the version number of the driver. The _init(9E), _info(9E), _fini(9E), getinfo(9E), open(9E), and close(9E) functions are the same as in Version 2 of the driver. Attaching, Allocating Memory, and Initializing a Mutex and a Condition VariableThe qotd_attach() entry point first allocates and gets the device soft state. The qotd_attach() routine then creates a minor node. All of this code is the same as in Version 2 of the Quote Of The Day driver. If the call to ddi_create_minor_node(9F) is successful, the qotd_attach() routine sets the QOTD_DIDMINOR flag in the new flags member of the qotd_state state structure. Version 3 of the Quote Of The Day driver defines four new constants that keep track of four different events. A routine can test these flags to determine whether to deallocate, close, or remove resources. All four of these flags are set in the qotd_attach() entry point. All four of these conditions are checked in the qotd_detach() entry point, and the appropriate action is taken for each condition. Note that operations are undone in the qotd_detach() entry point in the opposite order in which they were done in the qotd_attach() entry point. The qotd_attach() routine creates a minor node, allocates memory for the quotation, initializes a mutex, and initializes a condition variable. The qotd_detach() routine destroys the condition variable, destroys the mutex, frees the memory, and removes the minor node. After the minor node is created, the qotd_attach() routine allocates memory for the quotation. For information on allocating and freeing memory in this driver, see Allocating and Freeing Kernel Memory. If memory is allocated, the qotd_attach() routine sets the QOTD_DIDALLOC flag in the flags member of the state structure. The qotd_attach() routine then calls the mutex_init(9F) function to initialize a mutex. If this operation is successful, the qotd_attach() routine sets the QOTD_DIDMUTEX flag. The qotd_attach() routine then calls the cv_init(9F) function to initialize a condition variable. If this operation is successful, the qotd_attach() routine sets the QOTD_DIDCV flag. The qotd_attach() routine then calls the strlcpy(9F) function to copy the initial quotation string to the new quotation member of the device state structure. Note that the strlcpy(9F) function is used instead of the strncpy(9F) function. The strncpy(9F) function can be wasteful because it always copies n characters, even if the destination is smaller than n characters. Try using strncpy(9F) instead of strlcpy(9F) and note the difference in the behavior of the driver. Finally, the initial quotation length is copied to the new quotation length member of the state structure. The remainder of the qotd_attach() routine is the same as in Version 2. Checking for Changes, Cleaning Up, and DetachingThe qotd_detach() routine is almost all new. The qotd_detach() routine must first get the soft state because the qotd_detach() routine needs to check the flags member of the state structure. The first flag the qotd_detach() routine checks is the QOTD_CHANGED flag. The QOTD_CHANGED flag indicates whether the device is in the initial state. The QOTD_CHANGED flag is set in the qotd_rw() routine and in the qotd_ioctl() entry point. The QOTD_CHANGED flag is set any time the user does anything to the device other than simply inspect the device. If the QOTD_CHANGED flag is set, the size or content of the storage buffer has been modified. See Writing New Data for more information on the QOTD_CHANGED flag. When the QOTD_CHANGED flag is set, the detach operation fails because the device might contain data that is valuable to the user and the device should not be removed. If the QOTD_CHANGED flag is set, the qotd_detach() routine returns an error that the device is busy. Once the quotation has been modified, the device cannot be detached until the user runs the qotdctl command with the -r option. The -r option reinitializes the quotation and indicates that the user is no longer interested in the contents of the device. See Exercising the Driver's I/O Controls for more information about the qotdctl command. The qotd_detach() routine then checks the four flags that were set in the qotd_attach() routine. If the QOTD_DIDCV flag is set, the qotd_detach() routine calls the cv_destroy(9F) function. If the QOTD_DIDMUTEX flag is set, the qotd_detach() routine calls the mutex_destroy(9F) function. If the QOTD_DIDALLOC flag is set, the qotd_detach() routine calls the ddi_umem_free(9F) function. Finally, if the QOTD_DIDMINOR flag is set, the qotd_detach() routine calls the ddi_remove_minor_node(9F) function. Allocating and Freeing Kernel MemoryOne of the new members of the device state structure supports memory allocation and deallocation. The qotd_cookie member receives a value from the ddi_umem_alloc(9F) function. The qotd_cookie value is then used by the ddi_umem_free(9F) function to free the memory. Version 3 of the Quote Of The Day driver allocates kernel memory in three places:
The qotd_attach() routine allocates memory after the minor node is created. Memory must be allocated to enable the user to modify the quotation. The qotd_attach() routine calls the ddi_umem_alloc(9F) function with the DDI_UMEM_NOSLEEP flag so that the ddi_umem_alloc(9F) function will return immediately. If the requested amount of memory is not available, ddi_umem_alloc(9F) returns NULL immediately and does not wait for memory to become available. If no memory is allocated, qotd_attach() calls qotd_detach() and returns an error. If memory is allocated, qotd_attach() sets the QOTD_DIDALLOC flag so that this memory will be freed by qotd_detach() later. The second place the driver allocates memory is in the QOTDIOCSSZ case of the qotd_ioctl() entry point. The QOTDIOCSSZ case sets a new size for the device. A new size is set when the user runs the qotdctl command with the -s option. See Exercising the Driver's I/O Controls for more information about the qotdctl command. This time, the ddi_umem_alloc(9F) function is called with the DDI_UMEM_SLEEP flag so that ddi_umem_alloc(9F) will wait for the requested amount of memory to be available. When the ddi_umem_alloc(9F) function returns, the requested memory has been allocated. Note that you cannot always use the DDI_UMEM_SLEEP flag. See the CONTEXT sections of the ddi_umem_alloc(9F), kmem_alloc(9F), and kmem_zalloc(9F) man pages. Also note the behavioral differences among these three functions. The kmem_zalloc(9F) function is more efficient for small amounts of memory. The ddi_umem_alloc(9F) function is faster and better for large allocations. The ddi_umem_alloc(9F) function is used in this qotd_3 driver because ddi_umem_alloc(9F) allocates whole pages of memory. The kmem_zalloc(9F) function might save memory because it might allocate smaller chunks of memory. This qotd_3 driver demonstrates a ramdisk device. In a production ramdisk device, you would use ddi_umem_alloc(9F) to allocate page-aligned memory. After the current quotation is copied to the new space, the qotd_ioctl() routine calls the ddi_umem_free(9F) function to free the memory that was previously allocated. The third place the driver allocates memory is in the QOTDIOCDISCARD case of the qotd_ioctl() entry point. The QOTDIOCDISCARD case is called from the qotdctl command. The qotdctl command with the -r option sets the quotation back to its initial value. If the number of bytes allocated for the current quotation is different from the initial number of bytes, then new memory is allocated to reinitialize the quotation. Again, the DDI_UMEM_SLEEP flag is used so that when the ddi_umem_alloc(9F) function returns, the requested memory has been allocated. The qotd_ioctl() routine then calls the ddi_umem_free(9F) function to free the memory that was previously allocated. Managing Thread SynchronizationThe Quote Of The Day Version 3 driver uses condition variables and mutual exclusion locks (mutexes) together to manage thread synchronization. See the Multithreaded Programming Guide for more information about mutexes, condition variables, and thread synchronization. In this driver, the mutex and condition variable both are initialized in the qotd_attach() entry point and destroyed in the qotd_detach() entry point. The condition variable is tested in the qotd_rw() routine and in the qotd_ioctl() entry point. The condition variable waits on the QOTD_BUSY condition. This condition is needed because the driver must do some operations that rely on exclusive access to internal structures without holding a lock. Accessing the storage buffer or its metadata requires mutual exclusion, but the driver cannot hold a lock if the operation might sleep. Instead of holding a lock in this case, the driver waits on the QOTD_BUSY condition. The driver acquires a mutex when the driver tests the condition variable and when the driver accesses the storage buffer. The mutex protects the storage buffer. Failure to use a mutual exclusion when accessing the storage buffer could allow one user process to resize the buffer while another user process tries to read the buffer, for example. The result of unprotected buffer access could be data corruption or a panic. The condition variable is used when functions are called that might need to sleep. The ddi_copyin(9F), ddi_copyout(9F), and uiomove(9F) functions can sleep. Memory allocation can sleep if you use the SLEEP flag. Functions must not hold a mutex while they are sleeping. Sleeping while holding a mutex can cause deadlock. When a function might sleep, set the QOTD_BUSY flag and take the condition variable, which drops the mutex. To avoid race conditions, the QOTD_BUSY flag can be set or cleared only when holding the mutex. For more information on deadlock, see "Using Mutual Exclusion Locks" in Multithreaded Programming Guide and "Avoiding Deadlock" in Multithreaded Programming Guide. Locking Rules for Quote Of The Day Version 3The locking rules for this qotd_3 driver are as follows:
These locking rules are very simple. These three rules ensure consistent access to the buffer and its metadata. Realistic drivers probably have more complex locking requirements. For example, drivers that use ring buffers or drivers that manage multiple register sets or multiple devices have more complex locking requirements. Lock and Condition Variable Members of the State StructureThe device state structure for Version 3 of the Quote Of The Day driver contains two new members to help manage thread synchronization:
Creating and Destroying Locks and Condition VariablesVersion 3 of the Quote Of The Day driver defines two constants to make sure the mutex and condition variable are destroyed when the driver is finished with them. The driver uses these constants to set and reset the new flags member of the device state structure.
Waiting on SignalsIn the qotd_rw() and qotd_ioctl() routines, the cv_wait_sig(9F) calls wait until the condition variable is signaled to proceed or until a signal(3C) is received. Either the cv_signal(9F) function or the cv_broadcast(9F) function signals the cv condition variable to proceed. A thread can wait on a condition variable until either the condition variable is signaled or a signal(3C) is received by the process. The cv_wait(9F) function waits until the condition variable is signaled but ignores signal(3C) signals. This driver uses the cv_wait_sig(9F) function instead of the cv_wait(9F) function because this driver responds if a signal is received by the process performing the operation. If a signal(3C) is taken by the process, this driver returns an interrupt error and does not complete the operation. The cv_wait_sig(9F) function usually is preferred to the cv_wait(9F) function because this implementation offers the user program more precise response. The signal(3C) causes an effect closer to the point at which the process was executing when the signal(3C) was received. In some cases, you cannot use the cv_wait_sig(9F) function because your driver cannot be interrupted by a signal(3C). For example, you cannot use the cv_wait_sig(9F) function during a DMA transfer that will result in an interrupt later. In this case, if you abandon the cv_wait_sig(9F) call, you have nowhere to put the data when the DMA transfer is finished, and your driver will panic. Writing New DataThe cb_ops(9S) structure for Version 3 of the Quote Of The Day driver declares two new entry points that support modifying the quotation. The two new entry points are write(9E) and ioctl(9E). The qotd_rw() routine is a third new routine in Version 3 of the driver. The qotd_rw() routine is called by both the read(9E) entry point and the write(9E) entry point. The device state structure for Version 3 of the Quote Of The Day driver contains two new members that are used to modify the quotation. The qotd string holds the quotation for the current instance of the device. The qotd_len member holds the length in bytes of the current quotation. Version 3 of the driver also defines two new constants that support modifying the quotation. In place of QOTD_MAXLEN, Version 3 of the driver defines QOTD_MAX_LEN. QOTD_MAX_LEN is used in the qotd_ioctl() entry point to test whether the user has entered a string that is too long. Version 3 of the driver also defines QOTD_CHANGED. The QOTD_CHANGED flag is set in the qotd_rw() routine and in the qotd_ioctl() entry point when a new quotation is copied from the user. When the qotd_3 device is opened for writing, the kernel calls the qotd_write() entry point. The qotd_write() entry point then calls the qotd_rw() routine and passes a UIO_WRITE flag. The new qotd_read() entry point is exactly the same as the qotd_write() entry point, except that the qotd_read() entry point passes a UIO_READ flag. The qotd_rw() routine supports both reading and writing the device and thereby eliminates much duplicate code. The qotd_rw() routine first gets the device soft state. Then the qotd_rw() routine checks the length of the I/O request in the uio(9S) I/O request structure. If this length is zero, the qotd_rw() routine returns zero. If this length is not zero, the qotd_rw() routine enters a mutex. While the device is busy, the qotd_rw() routine checks whether the condition variable has been signaled or a signal(3C) is pending. If either of these conditions is true, the qotd_rw() routine exits the mutex and returns an error. When the device is not busy, the qotd_rw() routine checks whether the data offset in the uio(9S) I/O request structure is valid. If the offset is not valid, the qotd_rw() routine exits the mutex and returns an error. If the offset is valid, the local length variable is set to the difference between the offset in the I/O request structure and the length in the device state structure. If this difference is zero, the qotd_rw() routine exits the mutex and returns. If the device was opened for writing, the qotd_rw() routine returns a space error. Otherwise, the qotd_rw() routine returns zero. The qotd_rw() routine then sets the QOTD_BUSY flag in the flags member of the device state structure and exits the mutex. The qotd_rw() routine then calls the uiomove(9F) function to copy the quotation. If the rw argument is UIO_READ, then the quotation is transferred from the state structure to the I/O request structure. If the rw argument is UIO_WRITE, then the quotation is transferred from the I/O request structure to the state structure. The qotd_rw() routine then enters a mutex again. If the device was opened for writing, the qotd_rw() routine sets the QOTD_CHANGED flag. The qotd_rw() routine then sets the device to not busy, calls cv_broadcast(9F) to unblock any threads that were blocked on this condition variable, and exits the mutex. Finally, the qotd_rw() routine returns the quotation. The quotation is written to the device node. Reporting and Setting Device Size and Re-initializing the DeviceThe behavior of the ioctl(9E) entry point depends on the command value passed in to the entry point. These constants are defined in the new qotd.h header file. The qotd_ioctl() routine reports the size of the space allocated for the quotation, sets a new amount of space to allocate for the quotation, or resets the quotation back to its initial value. If the request is to report the size of the space allocated for the quotation, then the qotd_ioctl() routine first sets a local size variable to the value of the quotation length in the state structure. If the device was not opened for reading, the qotd_ioctl() routine returns an error. Because the qotd_ioctl() routine transfers data between kernel space and user space, the qotd_ioctl() routine must check whether both spaces are using the same data model. If the return value of the ddi_model_convert_from(9F) function is DDI_MODEL_ILP32, then the driver must convert to 32-bit data before calling ddi_copyout(9F) to transfer the current size of the quotation space. If the return value of the ddi_model_convert_from(9F) function is DDI_MODEL_NONE, then no data type conversion is necessary. If the request is to set a new size for the space allocated for the quotation, then the qotd_ioctl() routine first sets local variables for the new size, the new quotation, and a new memory allocation cookie. If the device was not opened for writing, the qotd_ioctl() routine returns an error. The qotd_ioctl() routine then checks again for data model mismatch. If the return value of the ddi_model_convert_from(9F) function is DDI_MODEL_ILP32, then the driver declares a 32-bit size variable to receive the new size from ddi_copyin(9F). When the new size is received, the size is converted to the data type of the kernel space. If the new size is zero or is greater than QOTD_MAX_LEN, the qotd_ioctl() routine returns an error. If the new size is valid, then the qotd_ioctl() routine allocates new memory for the quotation and enters a mutex. While the device is busy, the qotd_ioctl() routine checks whether the condition variable has been signaled or a signal(3C) is pending. If either of these conditions is true, the qotd_ioctl() routine exits the mutex, frees the new memory it allocated, and returns an error. When the device is not busy, the qotd_ioctl() routine uses memcpy(9F) to copy the quotation from the driver's state structure to the new space. The qotd_ioctl() routine then frees the memory currently pointed to by the state structure, and updates the state structure members to the new values. The qotd_ioctl() routine then sets the QOTD_CHANGED flag, exits the mutex, and returns. If the request is to discard the current quotation and reset to the initial quotation, then the qotd_ioctl() routine first sets local variables for the new quotation and a new memory allocation cookie. If the device was not opened for writing, the qotd_ioctl() routine returns an error. If the space allocated for the current quotation is different from the space allocated for the initial quotation, then the qotd_ioctl() routine allocates new memory that is the size of the initial space and enters a mutex. While the device is busy, the qotd_ioctl() routine checks whether the condition variable has been signaled or a signal(3C) is pending. If either of these conditions is true, the qotd_ioctl() routine exits the mutex, frees the new memory it allocated, and returns an error. When the device is not busy, the qotd_ioctl() routine frees the memory currently pointed to by the state structure, updates the memory state structure members to the new values, and resets the length to its initial value. If the size of the current quotation space was the same as the initial size and no new memory was allocated, then qotd_ioctl() calls bzero(9F) to clear the current quotation. The qotd_ioctl() routine then calls the strlcpy(9F) function to copy the initial quotation string to the quotation member of the state structure. The qotd_ioctl() routine then unsets the QOTD_CHANGED flag, exits the mutex, and returns. Once the QOTD_CHANGED flag has been set, the only way to unset it is to run the qotdctl command with the -r option. See Exercising the Driver's I/O Controls for more information about the qotdctl command. Quote Of The Day Version 3 SourceEnter the source code shown in the following example into a text file named qotd_3.c. Example 3-5 Quote Of The Day Version 3 Source File
Enter the definitions shown in the following example into a text file named qotd.h. Example 3-6 Quote Of The Day Version 3 Header File
Enter the configuration information shown in the following example into a text file named qotd_3.conf. Example 3-7 Quote Of The Day Version 3 Configuration File
Building and Installing Quote Of The Day Version 3Compile and link the driver. The following example shows compiling and linking for a 32-bit architecture:
Make sure you are user root when you install the driver. Copy the driver binary to the /tmp directory as discussed in Building and Installing the Template Driver.
Copy the configuration file to the kernel driver area of the system.
In a separate window, enter the following command:
Make sure you are user root when you load the driver. Use the add_drv(1M) command to load the driver:
You should see the following messages in the window where you are viewing /var/adm/messages:
Using Quote Of The Day Version 3This section describes how to read and write the qotd_3 device and how to test the driver's I/O controls. The I/O controls include retrieving the size of the storage buffer, setting a new size for the storage buffer, and reinitializing the storage buffer size and contents. Reading the DeviceWhen you access this qotd_3 device for reading, the command you use to access the device retrieves the data from the device node. The command then displays the data in the same way that the command displays any other input. To get the name of the device special file, look in the /devices directory:
To read the qotd_3 device, you can use the cat(1) command:
Writing the DeviceTo write to the qotd_3 device, you can redirect command-line input:
Exercising the Driver's I/O ControlsIn addition to changes in the driver, Quote Of The Day Version 3 introduces a new utility program. The qotdctl command enables you to test the driver's I/O controls. The source for this command is shown in Example 3-8. Compile the qotdctl utility as follows:
The qotdctl command has the following options:
Use the qotdctl command to test the driver's I/O controls:
By default, the qotdctl command accesses the /dev/qotd0 device. The qotd_3 device in this example is /devices/pseudo/qotd_3@0:qotd_3. Either define a link from /dev/qotd0 to /devices/pseudo/qotd_3@0:qotd_3 or use the -d option to specify the correct device:
If you try to remove the device now, you will receive an error message:
The device is still marked busy because you have not told the driver that you are no longer interested in this device. Run the qotdctl command with the -r option to unset the QOTD_CHANGED flag in the driver and mark the device not busy:
Enter the source code shown in the following example into a text file named qotdctl.c. Example 3-8 Quote Of The Day I/O Control Command Source File
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||