When a system running the Oracle Solaris OS is upgraded, new versions of drivers may be installed. During the upgrade process, the driver.conf file is also updated on the system. The driver.conf file is customized by both the vendor and the system administrator. During a system upgrade, the system's previous configuration should continue to work with the new drivers, the vendor's driver.conf file and with the administrator's driver.conf file.
In the Oracle Solaris 11 release, driver writers have an option to provide a separate driver.conf file that will contain the vendor provided driver data. The new driver.conf file is stored in the /etc/driver/drv directory. This enables the system to retain any administrative changes made to the file. If a driver is found in both the configuration files, the system will merge the files and present a file with the combined properties. The format of the vendor's driver.conf file is the same as the administrator's driver configuration file.
The vendor and administrative configuration data can now be made available to the driver explicitly via new interfaces. This enables the driver writer to encode any merge logic directly in the driver rather than in the class action scripts or the pre–install scripts and post–install scripts. The customizations made to the administrative file are preserved and the driver can decide on the relevance of the new values to the old values.
In order for a driver to ensure that the above model works well, the driver developer should consider the following:
Design the driver such that a set of disciplined, configurable options are available.
Describe fully the driver's options and the model in the driver documentation and man pages.
If the driver changes its configuration options such that the administrator settings are either invalidated or superseded, the driver should ensure that previous administrative settings are honored. To lookup the previous configuration, the driver can use the ddi_prop_lookup(9F) interface with the property type set to either DDI_PROP_VENDOR or DDI_PROP_ADMIN.
For example, if a driver supports a timeout configuration in units of seconds and a new version of the driver now supports a finer timeout granularity in units of milliseconds. The new property should be named such that it can be distinguished from the previous property. The driver should then look up the earlier property on the administrative list and if the property is found, the driver should continue to honor it. The following driver code illustrates the timeout example.
* Has the timeout been locally configured using the
+ * prior option of timeout in units of seconds?
+ */
+ if (ddi_prop_lookup_int(DDI_DEV_T_ANY, dip,
+ DDI_PROP_ADMIN, "timeout",&ivalues,&n) ==
+ DDI_PROP_SUCCESS) {
+ if (n != 1) {
+ ddi_prop_free(ivalues);
+ return (EINVAL);
+ }
+ /* yes - convert our working timeout accordingly */
+ dip->ms_timeout = 1000 * ivalues[0];
+ /* record the new parameter setting for confirmation */
+ (void) ddi_prop_update_int(DDI_DEV_T_NONE,
+ dip, "ms-timeout", dip->ms_timeout);
+ ddi_prop_free(ivalues);
+ }
The prtconf(1M) command displays the driver properties and the new –u option can be used to display the original property value and the changed property value.