ADD_DRV(8) | Maintenance Commands and Procedures | ADD_DRV(8) |
add_drv [-b basedir] [-c class_name] [-i 'identify_name...'] [-m 'permission','...'] [-p 'policy'] [-P privilege] [-n] [-f] [-v] device_driver
Each device on the system has a name associated with it. This name is represented by the name property for the device. Similarly, the device may also have a list of driver names associated with it. This list is represented by the compatible property for the device.
The system determines which devices will be managed by the driver being added by examining the contents of the name property and the compatible property (if it exists) on each device. If the value in the name property does not match the driver being added, each entry in the compatible property is tried, in order, until either a match occurs or there are no more entries in the compatible property.
In some cases, adding a new driver may require a reconfiguration boot. See the NOTES section.
Aliases might require quoting (with double-quotes) if they contain numbers. See EXAMPLES.
The format of the /etc/minor_perm file is as follows:
name:minor_name permissions owner group
minor_name may be the actual name of the minor node, or contain shell metacharacters to represent several minor nodes (see sh(1)).
For example:
sd:* 0640 root sys zs:[a-z],cu 0600 uucp uucp mm:kmem 0640 root bin
The first line sets all devices exported by the sd node to 0640 permissions, owned by root, with group sys. In the second line, devices such as a,cu and z,cu exported by the zs driver are set to 0600 permission, owned by uucp, with group uucp. In the third line the kmem device exported by the mm driver is set to 0640 permission, owned by root, with group bin.
When a package is being installed on the running system itself, the system files need to be updated, as in the case above. However, the running kernel can be informed of the existence of the new driver without requiring a reboot. To accomplish this, the postinstall script must invoke add_drv without the -b option. Accordingly, postinstall scripts invoking add_drv should be written thusly:
if [ "${BASEDIR:=/}" = "/" ] then ADD_DRV="add_drv" else ADD_DRV="add_drv -b ${BASEDIR}" fi $ADD_DRV [<options>] <driver>
...or, alternatively:
if [ "${BASEDIR:=/}" != "/" ] then BASEDIR_OPT="-b $BASEDIR" fi add_drv $BASEDIR_OPT [<options>] <driver>
The -b option is described below.
Note -
-c class_name
-f
-i 'identify_name'
-m 'permission'
-n
-p 'policy'
The device security policy constists of several whitespace separated tokens:
{minorspec {token=value}+}+
minorspec is a simple wildcard pattern for a minor device. A single * matches all minor devices. Only one * is allowed in the pattern.
Patterns are matched in the following order:
A missing minor spec is interpreted as a *.
-P 'privilege'
-v
The following example adds the SUNW,example driver to a 32-bit system, with an alias name of SUNW,alias. It assumes the driver has already been copied to /usr/kernel/drv.
example# add_drv -m '* 0666 bin bin','a 0644 root sys' \ -p 'a write_priv_set=sys_config * write_priv_set=none' \ -i 'SUNW,alias' SUNW,example
Every minor node created by the system for the SUNW,example driver will have the permission 0666, and be owned by user bin in the group bin, except for the minor device a, which will be owned by root, group sys, and have a permission of 0644. The specified device policy requires no additional privileges to open all minor nodes, except minor device a, which requires the sys_config privilege when opening the device for writing.
Example 2 Adding Driver to the Client /export/root/sun1
The following example adds the driver to the client /export/root/sun1. The driver is installed and loaded when the client machine, sun1, is rebooted. This second example produces the same result as the first, except the changes are on the diskless client, sun1, and the client must be rebooted for the driver to be installed.
example# add_drv -m '* 0666 bin bin','a 0644 root sys' \ -i 'SUNW,alias' -b /export/root/sun1 \ SUNW,example
See the note in the description of the -b option, above, specifying the caveat regarding the use of this option with the Solaris zones feature.
Example 3 Adding Driver for a Device Already Managed by an Existing Driver
The following example illustrates the case where a new driver is added for a device that is already managed by an existing driver. Consider a device that is currently managed by the driver dumb_framebuffer. The name and compatible properties for this device are as follows:
name="display" compatible="whizzy_framebuffer", "dumb_framebuffer"
If add_drv is used to add the whizzy_framebuffer driver, the following will result.
example# add_drv whizzy_framebuffer Error: Could not install driver (whizzy_framebuffer) Device managed by another driver.
If the -v flag is specified, the following will result.
example# add_drv -v whizzy_framebuffer Error: Could not install driver (whizzy_framebuffer) Device managed by another driver. Driver installation failed because the following entries in /devices would be affected: /devices/iommu@f,e0000000/sbus@f,e0001000/display[:*] (Device currently managed by driver "dumb_framebuffer") The following entries in /dev would be affected: /dev/fbs/dumb_framebuffer0
If the -v and -f flags are specified, the driver will be added resulting in the following.
example# add_drv -vf whizzy_framebuffer A reconfiguration boot must be performed to complete the installation of this driver. The following entries in /devices will be affected: /devices/iommu@f,e0000000/sbus@f,e0001000/display[:*] (Device currently managed by driver "dumb_framebuffer" The following entries in /dev will be affected: /dev/fbs/dumb_framebuffer0
The above example is currently only relevant to devices exporting a generic device name.
Example 4 Use of Double Quotes in Specifying Driver Alias
The following example shows the use of double quotes in specifying a driver alias that contains numbers.
example# add_drv -i '"pci10c5,25"' smc
/kernel/drv/sparcv9
/kernel/drv/amd64
/usr/kernel/drv
/usr/kernel/drv/sparcv9
/usr/kernel/drv/amd64
/platform/`uname -i`/kernel/drv
/platform/`uname -i`/kernel/drv/sparcv9
/platform/`uname -i`/kernel/drv/amd64
/etc/driver_aliases
/etc/driver_classes
/etc/minor_perm
/etc/name_to_major
/etc/security/device_policy
/etc/security/extra_privs
With the introduction of the device policy several drivers have had their minor permissions changed and a device policy instated. The typical network driver should use the following device policy:
add_drv -p 'read_priv_set=net_rawaccess\ write_priv_set=net_rawaccess' -m '* 666 root sys'\ mynet
This document does not constitute an API. /etc/minor_perm, /etc/name_to_major, /etc/driver_classes, and /devices may not exist or may have different contents or interpretations in a future release. The existence of this notice does not imply that any other documentation that lacks this notice constitutes an API.
/etc/minor_perm can only be updated by add_drv(8), rem_drv(8) or update_drv(8).
In the current version of add_drv, the use of double quotes to specify an alias is optional when used from the command line. However, when using add_drv from packaging scripts, you should continue to use double quotes to specify an alias.
May 13, 2017 | OmniOS |