STREAMS Module Configuration
The following example shows the structures you need if you are working with a module instead of a driver. Notice that a modlstrmod(9S) is used in modlinkage(9S), and fmodsw(9S) points to streamtab(9S) instead of going through dev_ops(9S).
cc -D_KERNEL -c example_one.c cc -D_KERNEL -c example_two.c as -P -D_ASM -D_KERNEL -I. -o example_asm.o example_asm.s ld -r -o example example_one.o example_two.o example_asm.o
See Writing Device Drivers for more information on the sequence of installing and loading device drivers. The basic procedure is to copy your driver to /kernel/drv and your module to /kernel/strmod. For drivers run add_drv(1M).
Note - The autoload facility looks for modules to reside in /kernel/strmod. If the object resides elsewhere the module will not be loaded.
Checking the Module Type
if (sflag == MODOPEN) /* then the module is being pushed */ else if (sflag == CLONEOPEN) /* then its being opened as a clonable driver */ else /* its being opened as a regular driver */
Certain system parameters referred to by STREAMS are configurable when building a new operating system (see the file /etc/system and the SunOS User's Guide to System Administration for further details). These parameters are:
STREAMS Administrative Driver
The autopush(1M) facility configures the list of modules for a STREAMS device. It automatically pushes a prespecified list (/etc/iu.ap) of modules onto the stream when the STREAMS device is opened and the device is not already open.
The STREAMS Administrative Driver (SAD) (see the sad(7D) man page) provides an interface to the autopush mechanism. System administrators can open the SAD driver and set or get autopush information on other drivers. The SAD driver caches the list of modules to push for each driver. When the driver is opened the stream head checks the SAD's cache to determine if the device is configured to have modules pushed automatically. If an entry is found, the modules are pushed. If the device has been opened but not closed, another open does not cause the list of the prespecified modules to be pushed again.
Three options configure the module list:
Configure for each minor device (that is, a specific major and minor device number)
Configure for a range of minor devices within a major device
Configure for all minor devices within a major device
In addition, when configuring the module list, an optional anchor can be placed within the module list. See "STREAMS Anchors" for more information.
When the module list is cleared, a range of minor devices has to be cleared as a range and not in parts.
The SAD driver is accessed through the /dev/sad/admin or /dev/sad/user node. After the device is initialized, a program can perform any autopush configuration. The program should open the SAD driver, read a configuration file to find out what modules need to be configured for which devices, format the information into strapush structures, and make the SAD_SAP ioctl(2) calls. See the sad(7D) man page for more information.
All autopush operations are performed through SAD_SAP ioctl(2) commands to set or get autopush information. Only the root user can set autopush information, but any user can get the autopush information for a device.
The SAD_SAP ioctl is a form of ioctl(fd, cmd, arg), where fd is the file descriptor of the SAD driver, cmd is either SAD_SAP (set autopush information) or SAD_GAP (get autopush information), and arg is a pointer to the structure strapush.
The strapush structure is shown in the following example:
Example 11-3 strapush Structure