jeffz@sun.com (Jeffrey Zank - SBus Software) (07/27/90)
One friendly reader has pointed out that it is possible to modload STREAMS drivers without hacking up the "vd" driver. Thanks to Jim Foote for serving up some humble pie. Here it is/have fun. Jeffrey Zank "my views are my own, at least until my wife gets home!" ----- Begin Included Message ----- X-From: Foote.osbunorth@Xerox.COM Mark Weiser forwarded your message - I thought I should let you know what we did to make our streams drivers loadable. Basically I took the loadable device driver example from the Writing S Bus Device Drivers manual and munged it around until I got it to work for my pseudo device (XNS). There were basically 3 problems that had to be overcome: 1. Workaround the differences between the vdldrv data structure in the sun4 and sun4c versions of /usr/include/sun/vddrv.h to allow us to have a single modloadable driver regardless of the kernel architecture. We could have worked around this by maintaining two different drivers. See FIRST UGLY HACK below. 2. Fill in the fmodsw entries manually during modload initialization (this step is one that eventually we'd expect vddrv to support). See SECOND UGLY HACK below. 3. Workaround the current architecture of modload which is designed to support a driver with a one to one mapping of cdevsw (or bdevsw) entries to modloadable object files rather than more than one cdevsw entry for a single modloadable object file. We did this by encoding the minor device numbers for the other cdevsw entries in the modstat data structure - then used smarts in the xnsdrv.INSTALL script to turn these into MKDEV calls. See THIRD UGLY HACK below. Obviously there would be more work for more complicated streams drivers, but it wasn't all that tough to get this working. The only other beef is that the Sun supplied /usr/sys/sun/conf.c doesn't have enough empty vddrv slots! The vddrv architecture still has some rough edges, but we're very pleased with the dynamic loading direction. -- Jim