Porting Considerations

With the self-configuring kernel, Solaris 7 drivers will look more like SBus drivers than other types. All drivers are loadable, and no kernel configuration is required.

Under the SunOS release 4.x software, only one processor could be in the kernel at any one time. This was accomplished by using a master lock around the entire kernel. When a processor wanted to execute kernel code, it would acquire the lock (excluding other processors from running the code protected by the lock) and it would release the lock when it finished.

The Solaris 7 kernel is multithreaded. Instead of one master lock, there are many smaller locks that protect smaller regions of code. For example, there may be a kernel lock that protects access to a particular vnode, and one that protects an inode. Only one processor can be running code dealing with that vnode at a time, but another could be accessing an inode. This allows a greater amount of concurrency.

The multithreaded kernel will have a major impact on how you design the driver. The old model of using splN/splr pairs no longer works (on a uniprocessor or a multiprocessor system [Strictly speaking, the splN/splr pair do work; however, although they will block interrupts, the effect is useless in protecting data structures in a multiprocessor environment.] ). Instead, you have a choice of MT-style locks. The most common of these for drivers will be mutual exclusion locks, mutexes, and condition variables (which are an approximate equivalent of sleep()/wakeup() synchronization).

The old notion that you owned the processor until you explicitly called sleep() is no longer true. Because of kernel pre-emption, the CPU is switched from thread to thread so you must use the appropriate MT lock primitives to guard against concurrent access to device registers, shared data structures, and the like.

A large percentage of the driver code for simple device drivers, which consist primarily of calls to kernel interface routines, will change, but in straightforward ways. For complex device drivers (such as a SCSI driver) which contain large amounts of device-specific handling code, only a small percentage of the driver--the driver interfaces--changes. This driver interface can be a kernel-to-driver interface, a driver-to-kernel interface, or a driver-to-driver interface.

Before you determine how you will support a driver in the Solaris 7 operating environment, refamiliarize yourself with how the driver works. Determine what the SunOS release 4.x driver did (not the specific implementation, but general behavior). What interfaces did it export? What ioctl()s did it provide? How did the hardware work and what peculiarities of the hardware did the driver support? Did the driver support multiple open() calls?

The following changes affect drivers and should be considered:

• The entry points to drivers are very different

• ANSI C requirements:

  • volatile keyword

  • const keyword

  • Function prototype declarations

• Relocated or renamed header files (most, if not all, system header files are now in /usr/include/sys)

• Most structures have become opaque or are no longer needed. For example:

  • struct user

  • struct proc

  • struct dev_info